Spotify API Authorization Flow with React and Rails
For my final project, I am building a data analysis app using the Spotify API (update: check out the final product here). It seemed that every time I told someone I was using it, they would wish me luck. Apparently it's notoriously complicated.
Boy were they right. Check out the authorization flow, which might have you whipping your head around like the adorable kittens above trying to follow what you need to do to get some dang user data:
I was able to find plenty of examples of how to set this monster up using Node and Rails, but failed to find anything that could help me set it up using a React front end and a Rails API. However, after a bit of hair pulling over the previous couple days, I am proud to say I finally cracked the code (pun intended). Continue reading below for a quick walk through on how I implemented it in my app. Hopefully my pain and frustration can save you some time!
Step 1: Application requests authorization to access data
This step took me way longer than it should have. I kept trying to have my rails back end send the request with the parameters, to which I only ever got a 201 response telling me there was no data. However, somewhere out in the deep dark web, I stumbled upon a forum post where a user asked a similar question, and someone from Spotify helpfully responded that it is not something your application sends to spotify, but rather a URL you needed to send as a redirect or popup to the user’s browser. Whoever you are out there — THANK YOU!
With this knowledge in hand, I created the the following button in my React app (with some help from Semantic UI React:
The button simply serves as a link that makes a call to my Rails API, which is tasked with creating the GET request URL with the correct parameters. This controller action then redirects the user’s browser to that URL:
Step 2: Spotify Accounts Service displays scopes & prompts user to log in and step 3: user logs In
This is the easy part — Spotify takes over and displays the following screens to the user:
Once the user has logged in and accepted the scopes (i.e. the specific pieces of data you want to access), Spotify’s Account Services redirects them to the redirect url that you provided in the GET request from step 1.
Step 4: Application requests access and refresh tokens
In my Rails API, the redirect url I provided to Spotify is associated with the #create action of the UsersController:
Spotify’s Account Service sends an access token in the response body (assuming the user agrees to let your app access their data — if not the response body has an error). You then need to use this token to ask Spotify for two more tokens that are specific to the user: an access token and a refresh token. <Insert token joke about tokens here>.
I structured that request as follows:
Step 5: Spotify Accounts Services returns access and refresh tokens and step 6: application uses token in requests to Web API
The response body of the request above contains our coveted tokens. Using the access token, you can finally query the Spotify API for the user data that you have been approved for. In the code below I use this token to get the user’s profile information, which I then save along with the access and refresh tokens in my database:
Awesome! We’re good to go right!? WRONG!
Step 7: Application requests refreshed access token
User access tokens expire 3600 seconds — or 1 hour — after they are created (which is indicated in the response header from step 5). Spotify’s API will helpfully tell you that the access token you are trying to use has expired, but that means you need to plan to resend any request that fails for this reason…
I figured a better path forward would be to check before each API call whether the user’s token had expired, and if so get a new one before sending another request. In order to give myself some buffer time, I created a method in the User model to check whether or not a token was 55 minutes old or not:
This function is then used in my Spotify API Adapter to check whether or not I need a new token:
As you can see, this part is still a work in progress — this guide is hot off the presses! Once I have set up my user authorization flow, I will simply use current_user, which is a method that returns the user that is currently logged in to the app. For now, I’m hardwiring it to be my own user id/account.
Next Steps
Now that I have my app authorizing users through the Spotify API and automatically refreshing tokens when necessary, there is just one additional step I need to set up:
Add the refresh_token method to a before_action, ideally unique only to the Spotify API Adapter so I don’t have to add skip_before_action callbacks to all my other controllers. This way, I can DRY up my code and make API requests always knowing that a token will be valid. I tried to implement this right before writing this post, but something wasn’t working. Definitely a problem for tomorrow.
I will of course update this blog once I have that figured out, but for now that is where I will leave you!
