Best way to support social logins but also always return access tokens for our own APIs

Question

We'd like to support both local account login and social logins through Facebook, etc. for our application. After the user authenticates, we'd like to return an access token for the user to access our own APIs. However, with social login using OAuth/OIDC, the access token returned would be for the social identity provider APIs, not tokens to access our own APIs / user's data for our application. In this case, is it usually recommended to use an identity broker or extend our own OAuth2 server to support multiple logins but always return the access token for our own API at the end?

I'm wondering if it's possible to support plain OIDC/OAuth social login, and then only later get the access token to access the user's data for our application (i.e. the access token for our own APIs) to use when needed to call our own APIs. But not sure how this would work, or if it's possible.

Answer 1

What you describe is the standard OAuth solution from RFC6749, which should work like this:

• App runs a code flow and redirects to the authorization server (AS)
• AS runs another code flow and redirects to the social login identity provider (IDP)
• Or existing users and passwords can be migrated to AS to continue to support existing logins
• User authenticates
• IDP returns tokens to AS
• AS returns tokens to app

The key behaviour is that the app receives an access token for its own APIs. This access token contains scopes and claims that you can fully control, so that access tokens are locked down and APIs can authorize access to data correctly.

The wrong way to do it is to code social logins directly into your apps. Doing so results in them receiving foreign access tokens that are not useful to your own APIs.

Using an AS also reduces security code in apps, and scales well as the number of apps and authentication methods they use grows.