Multiple authentication providers and JWT sub

Help
, ,
1

I have seen this question asked in a couple of ways on these forums and elsewhere. Forgive me if I am repeating those question but I wanted to be explicitly clear about this point.

Given:

  1. I have two or more auth providers (database and social)
  2. A user registers with a username and password
  3. The express application database (not the auth0 db) has items created using the user_id from the user creation process
  4. The user logs in with a social provider

Question:

Will the sub of the JWT sent to the express application match the user_id received when the user registered? I know the user_id is set using the first identity the user registered with. I want to ensure that using a different identity for the same user will consistently return the same value for sub in the JWT.

2

The user identifier user_id will be unique on each user identity (aka type of authentication; aka connection).

If an end-user, John Doe, authenticates with a database connection a user identifier will be assigned to that user identity, for example, ID34. If the same end-user then perform a logout and proceeds to authenticate with a social provider another user identifier will be assigned to that user identity, lets say, ID82.

At this stage, for a single person, both Auth0 and your application will think that there two different users. We then support the concept of account linking which enables the same person to link multiple identities into a single user account and in this way be allowed to authenticate in multiple ways, but with the assurance that the application will see a normalized view of the user no matter the identity used to verify who the user is.

However, there’s multiple ways of implementing account linking and there will be considerations associated to each one. For example, if you implement account linking through a rule that automatically links user identities based on the same verified email then you’ll need to take in consideration that the user identity that initiated the transaction should be considered the primary and any existing user identity with the same email will be secondary. In this situation, you could say the user identifier for an existing user will change because the resulting linked user account will use the identifier associated with the primary identity and the primary identity is the one that just logged in for the first time.

If you want to use account linking and maintain absolute control on which user identity is treated as primary then I would not recommend using a rule to perform automatic account linking. Ideally this should be handled in your client application back-end; you could still use a rule that checks for other identities with the same verified email and includes a custom claim in the issued ID token. Your client application would then detect the custom claim and inform the user that they already authenticated using the same email and as such their identities will be linked (at this point you could control which one would be used as primary). Have in mind that you still need to decide on how you handle the user identifier situation; for example, you could force the user to authenticate again after having performed the linking and in this way the returned sub would be the one associated with the primary identity you chose which would allow you to basically ensure that it would be the one that already has data associated with it in your client application.

In conclusion, if you make use of account linking then depending on how you perform it you may observe user identifier changes.

1 Like
3

Thank you for such a detailed answer. I have not given any thought to account linking yet since I have not added a social provider but you bring up some very good points. Thanks again.