Best practice for accessing external API when using 3rd party provider

[camerondrysdale]

In our architecture we have our database and essentially our business logic and data (inc. users) centralised and accessible via an API. This API is accessible using a token that traditionally would be retrieved by sending a username and password to an auth endpoint and returning said token to be used to authenticate against subsequent endpoints to send and retrieve data.

We're looking to replace this auth endpoint with Oauth... but more on that in a minute.

First we'd like to enable logging in with a 3rd party Provider e.g. Google. However because Google would just return their own access tokens and we need to talk to our own API using our own token, so we need to get a user that exists on our end and then also get a token that can be used to talk to the API itself.

One idea we have so far is on the signIn callback we'd send the idToken to our InternalAPI and then lookup the user and verify them etc...

callbacks: {
  async signIn({ user, account, profile, email, credentials }) {
    if(account) {
      user = InternalAPI.verify_account(account.idToken) // this does a fetch and verifies the JWT against the Provider's JWK
      if(user) return true
      
      return false
     }

    return false
  }
}

It would then return true if they existed, however we'd not still not have a token for our own API... and we'd like to allow a user to login via Google, Facebook, and as mentioned earlier our own Oauth Provider, so verifying the idToken with the correct provider becomes a bit more complex... do we need to pass the provider as well? Is this considered the best practice with multiple providers?

At this stage, we've essentially logged into the app with Google using NextAuth, but we haven't logged into our API with Google. It seems quite messy having to login app-side, then send some data to the server to get another token, that is then used to talk to the API... but this seems like the only solution (if we want to use NextAuth directly with the 3rd party providers).

An example of how this might work is on the JWT callback to get a token from our server using the idToken:

async jwt({ token, user, account, profile, isNewUser }) {
  access_token = InternalAPI.get_token(account.idToken)
  token.access_token = access_token
  return token;
}

on our Provider (which uses Doorkeeper Rails gem) we would generate a token manually instead of via the usual Oauth flow:

user_id = # // look up the user from the DB using the JWT idToken
access_token = Doorkeeper::AccessToken.find_or_create_for(application: nil, resource_owner_id: user_id)
render json: { access_token: access_token }

This seems like a lot of work... just to use our own UI in the app...

It seems that if you want to persist your users in an external DB, access this data via an external API using a token (different to what's returned from a 3rd party Provider), and login using 3rd party Providers such as Google, as well as login with your own Provider (if need be), it seems the better solution is for the entire authentication and login UI to happen on the Provider itself and then have NextAuth use a custom provider instead of configuring each of the providers on the app:

{
  id: "internalAPI",
  name: "internalAPI",
  type: "oauth",
  authorization: { params: { scope: "email profile" } },
  idToken: true,
  checks: ["pkce", "state"],
  profile(profile) {
    return {
      id: profile.id,
      name: profile.name,
      email: profile.email,
      image: profile.image,
    }
  },
}

If the user wanted to login with Google, then the Oauth login form presented to them would show this as an option. However this does mean you lose the ability to style up the auth forms app-side and use your own components and must rely entirely on the look and feel of the Provider which in the case is our Rails app... but if we used Keycloak for example it'd be more limited.

Is there an alternative way of handling this? Allowing NextAuth to talk directly to 3rd party providers but also talk to your own API's using tokens generated for that API... or is the way I've described it up top the way to do this?

[itayb1]

Would like to hear in which way you eventually decided to accomplish this. @camerondrysdale