Search code examples
securityoauth-2.0authorizationspotify

Authorization Code Flow, sending the code from a mobile app to a REST API

I'm building a mobile app (and possibly a website) that uses a REST API to handle all the logic.

That being said, the REST api itself should call a 3rd party REST API (the Spotify one) to handle the logic for the app/website.

So basically the user should sign in to my app/website using its Spotify account and my API should make calls to the Spotify Web Api to retrieve user data using its access token, and then send them back to the app/website.

Now I've spent quite some time studying Spotify guidelines about authentication here and it looks like the Authorization Code Flow should fit my use case.

I definitely need to call the /authorize endpoint to retrieve the code from my app since I need user interaction for that. After that, I do get back the **code** that I should exchange for an access_token and refresh_token.

But as I said, it's not the app itself the makes the calls to the Spotify API, but my API. So theoretically I should send the received code to my API and let him handled retrieving and refreshing the access_token and refresh_token.

So my question is if this makes sense? Is it ok to send the code from the app to my api? Not sure if it's clear so I'll attach a diagram of what I'm intending of doing.

enter image description here

Also probably after receiving the code, I would send back my own token to the app to be used with each future request (somehow similar with what you would do when you handle authorization with Facebook or other socials)

Solution

  • Hmm - some assumptions below, but I would aim to use standard flows. Some solutions are not possible in a good way though.

    BUSINESS SOLUTION

    Are you trying to build an app that combines the user's Spotify data with your own data for the user?

    ARCHITECTURE TO AIM FOR

    Your own UIs and APIs should use tokens issued by you and not Spotify. Only use Spotify tokens when you need to access Spotify resources. This leads to simple and reliable code.

    STANDARD OPTION 1

    This is based on you being in control of data from multiple sources:

    • You should have your own login and token issuing system. UI first logs into your app, which enables it to call your API with a token.

    • When you want to access Spotify you need to redirect the user again. The user can then consent to you using Spotify resources in your app, after which your web / mobile UIs get a Spotify token and can call Spotify APIs.

    STANDARD OPTION 2

    This is based on allowing the user to sign in with a familiar credential, which works via a federated login:

    • User needs to login
    • Your app redirects to your Authorization Server
    • There is a second redirect to Spotify
    • User logs in at Spotify
    • Spotify posts a token to your Authorization Server
    • Your Authorization Server posts its own token to your mobile app

    Meanwhile your Web API has its own connection to Spotify that uses the Client Credentials Flow.

    DOUBLE HOPPING CODES / TOKENS

    This is not insecure, but it will add a lot of complexity and is not standard. You would need to maintain some kind of API session with 2 types of token per user and access token expiry would be a horrible area.

    MOBILE FLOW

    For mobile apps you should use Authorization Code Flow (PKCE) - my blog posts have some stuff on messages and user experience.