I have an app that revolves entirely around Spotify. I have followed the authorization guide from Spotify and am using the Authorization Code Flow so the access token can be refreshed. My thinking was that this will prevent them from having to log back into Spotify each time they return to the app, but I'm not sure how to do this securely.
For authorization, they are taken to the Spotify page to authenticate and grant my app access to to the requested scopes. After being redirected to my React application, the authorization code is forwarded to my REST API server so it can grab an access and refresh token.
At this point, I'm wondering:
- Should I store the refresh token in the DB? Wouldn't I need to encrypt it?
- Should I return the access token to my React app so that it can include it in subsequent requests to my API?
Since I'm storing their Spotify id in my DB, it seems like I could use the access token to hit https://api.spotify.com/v1/me to get this id and look them up in my database to make sure they're authorized to access the requested resources both on my server and on Spotify's in one shot. It seems like this would prevent them from needing to have a separate authentication just for my app, since everything is tied to Spotify anyway.
My concern with this approach is that it seems insecure. If a malicious entity acquires one of my user's tokens, I'm afraid they would have eternal access, since I'm refreshing the token on behalf of the user as specified by the Authorization Code Flow.
So, I'm considering having my own authentication (AWS Cognito) in addition to Spotify authorization.
It seems like leveraging Cognito for authentication would allow me to make sure it's them just by verifying the JWT. Then, I can look them up in my DB by the JWT sub. This seems like the cleaner way to do things, but it leaves me with questions:
- Wouldn't I then need to store their Spotify access token in my DB as well? Wouldn't I need to encrypt it?
- Is this this some sort of anti-pattern, since the user has to sign in with me and sign in with Spotify? I can't seem to rationalize why this is different from any other federated idP flow, like how Cognito lets FB, Google, etc. be leveraged for sign in to authenticate users with my app. They're signing in with Spotify already, so I'm confused as to why there needs to be an extra step of also having to sign into my app.
I have read the OAuth 2.0 RFC 6749 documentation, the OpenID Connect documentation
I have also read a plethora of posts (and the links within them), including, but not limited to:
- OAuth2 and Authentication
- Storing third party API tokens in a database
- Should client have access to 3rd party API access token?
- https://medium.com/@abstarreveld/oauth-and-openid-explained-with-real-life-examples-bf40daa8049f
- https://stackoverflow.com/questions/57379459/auth-strategy-for-aws-api-gateway
- https://stackoverflow.com/questions/32236568/how-to-set-up-an-oauth2-authentication-provider-with-aws-api-gateway/33686216#33686216
- https://stackoverflow.com/questions/42734848/access-token-to-encrypt-or-not
