ios-sdk
ios-sdk copied to clipboard
How to do Token Refresh
Hi,
In the old SDK we should check for an active token and refresh if expired by doing something amongst the lines:
SPTAuth *spotifyAuth = [SPTAuth defaultInstance];
if (spotifyAuth.session == nil) { }
if ([spotifyAuth.session isValid]) { }
if (spotifyAuth.hasTokenRefreshService) { }
Do we need to do something similar in this new SDK? Or is token refresh automatically handled once given a tokenSwapUrl to the SPTConfiguration instance? Thank you.
The Spotify documentation outlines token swap / refresh here
According to the documentation:
By setting tokenSwapURL and tokenRefreshURL it is possible for the iOS-SDK to request a new access token with a refresh token whenever needed.
You can set these URL's when you are configuring the SPTConfiguration instance. An example might look like this:
private lazy var configuration: SPTConfiguration = {
let configuration = SPTConfiguration(clientID: SpotifyClientID, redirectURL: SpotifyRedirectURI)
configuration.playURI = ""
configuration.tokenSwapURL = URL(string: "swapurl")
configuration.tokenRefreshURL = URL(string: "refreshurl")
return configuration
}()
If you follow the instructions here, you can easily set up a Heroku instance to provide the swap and refresh functionality for you, although it's not recommended to use it in production. Then you would simply replace "swap url" and "token url" with the url's from the Heroku instance.
@jonahpelfrey I keep seeing so many places in the Spotify documentation that say the token exchange processes are "not recommended to use in production". Does there exist an example or suggested way to actually do this in production?
@katehuds I think they are making a recommendation against using their example token swap because in a production environment, it should be a part of the application backend.
In terms of building out an authorization flow, Spotify also outlines this here. They outline Authorization Code, Implicit Grant, and Client Credentials Flow (Three different authorization patterns).
There are other resources on authorization, but this should give you a good idea on how to structure an authorization system to use with Spotify. Does that answer your question?
@jonahpelfrey I'm very new to app development, so I'm sorry if these questions sound naive.
When you say "part of the application backend", would this be using something like Firebase, through the authentication feature? The practice app I'm working on only needs to keep track of a pretty small amount of data, so I've just been saving it in the UserDefaults. I guess if the amount of data that needs to be kept is bigger, then it would require a database and the user to create a login, in order to keep it all.
I've been using the SPTLoginSampleAppSwift example provided by Spotify which utilizes the authorization Code flow, but just with the local host server running. I didn't realize I couldn't just host a server (like on Heroku) and continue to use this implementation of the authorization code flow.
@jonahpelfrey Sorry to bother you, I just want to make sure I'm on the right path with this.
Thanks in advance!
@katehuds No worries. Yes when I say application backend it could be something like firebase.
To be more clear on the phrase "not recommended to use in production" -- If you are building a sample app (which it sounds like you are) don't worry about this comment. Use the Heroku deployment option / run it locally.
If you hope to publish this app, you might want to revisit this discussion. Firebase is a good option for storing / authenticating users, but not necessary for a practice project.
@jonahpelfrey Thanks for the response! I've been running it locally since I started working on the app. I am definitely interested in publishing it at some point, so I'm trying to make sure I understand what is needed prior to doing that.
The process for Authorization Code Flow (Controlling the flow of authorization instead of implicitly granting authorization) is outlined in a README here:
https://github.com/bih/spotify-token-swap-service/blob/master/README.md#authorization-code-flow
If you wanted to replace the above heroku example with your own API, it would just need to provide the outlined functionality. Then your API would allow you to control if and when new tokens should be requested, with the client facing app having only to communicate with your API to request the current token.
@jonahpelfrey I'm a bit late to the party, but I am struggling with similar issues. I managed to create my exchange backend for token swap and refresh and also the initial authorization in my SwiftUI app works well. However I am unsure whether I need to manually fetch a new token from the exchange service or the SDK does the work for me automatically. I was a bit confused because you can actually set the refresh url for the SDK but whenever I try to reconnect after I disconnected from the remote playing api I get errors. Not sure if I understood correctly how it should work ...