Is it possible to replace the returned id_token in Auth0 rule

Help
,
1

Hi there

I am trying to normalise Auth0 users when they sign up. Basically our users can sign up with email/password or Gmail or Facebook. We want to have Username-Password-Authentication as primary identity for every user even if they sign up with Gmail or Facebook.

Here’s what I want to do (in Auth0 rule):

  1. Let’s say users sign up using Gmail. And we create another Auth0 user using their email and a generated password.
  2. Then we link the user with Gmail and the user with email/password. The email/password one should be the primary identity.
  3. As the user_id changes we need to sign in with the email/password user so we get the id_token.

My question is how can I return the new id_token (in Auth0 rule) so that the id_token we get in our SPA is for the email/password user, not the initial Gmail user.

2

You should avoid that scenario through rules because linking a user identity means that the secondary user identity is removed from the system in terms of it being a standalone account. When a user authenticates through Google and you automatically provision a database user and link both while treating the Google identity as secondary in practice the user that is currently in the middle of an authentication process is removed and this will likely lead to issues.

If you want to automatically provision database users and use them as the primary identity for linked accounts you should do the linking process after the user authentication process (based on a social provider) completes. For example, the client application would receive a Google identity detect there’s no associated username/password identity and trigger the automatic provision and linking of the database user as the primary. However, this implies that your client application will receive an ID token associated with a social user the first time they login.

1 Like
3

I’ve thought about your idea. The problem is the client application will have ID token and SSO cookie associated with the social user. It’s possible to update ID token in client application, but we can’t update SSO cookie without asking user to login again.

I found another feature which could be useful to solve the problem: impersonation. We can have server side to generate impersonation URL associated with the DB user and return to the client application. By redirecting to the URL both ID token and SSO cookie will be switched to the DB user.

Just a thought, I am going to try it.

4

I’ve thought about your idea. The problem is the client application will have ID token and SSO cookie associated with the social user. It’s possible to update ID token in client application, but we can’t update SSO cookie without asking user to login again.

I found another feature which could be useful to solve the problem: impersonation. We can have server side to generate impersonation URL associated with the DB user and return to the client application. By redirecting to the URL both ID token and SSO cookie will be switched to the DB user.

Just a thought, I am going to try it.

5

The solution we used finally is some front-end logic. Here’s how it works:

  1. After user signs up with social identity (Google, Facebook, etc.), we have JS logic to run in browser to sign out the user so the SSO cookie is also cleared.
  2. As we know the identity provider (Google, or Facebook, etc.) and the email address user signed up with, we can have another JS logic to sign in the user immediately after user is signed out in the above step. There are special parameters in auth0 sign in request to indicate identity provider and email address. Because the browser still keeps the Google/Facebook session, the sign-in process can happen without user’s interaction.