@uptiie You seem to be overcomplicating things. OAuth is an authorisation protocol to allow other services to act as another user. It does this through access tokens. So when you “sign in” with Facebook, you get an access token for your account on Facebook. When you “sign in” with Twitter, you get an access token for your account on Twitter. When you “sign in” with Spotify, you’ll get an access token for your account on Spotify.
If a user can connect multiple accounts to their account on your service, then you’ll need to save these access tokens issued with these third-party websites in a table somewhere. A table called access_tokens is perfectly fine that has a foreign key pointing to the user who owns the token, then columns for data like the access token value, refresh token if one was provided, when the refresh token expires, and a “name” for the account if that’s what your application requires. You’ll then use the access tokens issued by third parties (such as Spotify) to authenticate as that user when using Spotify’s API to retrieve tracks or whatever. Same deal with Pandora.
You’ll need to store any refresh tokens you receive as well. Reason being, OAuth 2 access tokens usually have an expiry date. So if the access token expires, you’ll no longer be able to make API requests with it. So your users will be annoyed if after a month or so your service stops working. So you use the refresh token to get a fresh access before the access token expires. If the access token expires, so does the corresponding refresh token. So you won’t be able to refresh an access token after it has expired. The simplest way to do this would be to have a scheduled task that checks for any access tokens expiring in say, the next three days, and dispatch queue jobs to refresh them. For any that you can’t refresh (i.e. the user’s revoked the token, de-authorized the app, etc) you can send them a notification saying their account’s been disconnected and prompting them to re-connect.