Decode session token in continue action

Get Help
,
4

Thanks for the response. I apologize, but your explanation doesn’t quite make sense to me. Perhaps I wasn’t very clear when describing my case.

Here’s my situation:

  1. The user logs in using Auth0.
  2. Then, a custom action triggers and utilizes the Management API to check if another user with the same email exists in Auth0. If yes, the system redirects to a linking service (my own Next.js app). Before the redirect, the Auth0 action also creates a session token using api.redirect.encodeToken and includes the found identities in the payload.
  3. In the linking service, the session token is validated and decoded. It displays the end-user identities to link with and requests authentication using the chosen identity.
  4. Once the identity ownership is verified (using OIDC implicit flow), the Management API is used to link the user identity who initiated this flow (user from step 1) with the just-verified identity from step 3. Upon completion, it redirects back to the Auth0 action using the /continue URL and provides a NEW session token created by myself and a state received upon redirect from custom auth0 action. The payload of this token is simple; it only includes the payload required by Auth0 to validate it (sub, iss, state), and the new user_id, which is now primary.
  5. In the Auth0 continue action, I validate this token and set the new primary identity for the user.

And so in step 5 token validation never passed… I provided not OBFUSCATED tokens because, clients can see them in query params, and it’s a test tenant, and for your information.

The thing is, the tokens you’re referring to as access tokens are not actually access tokens but custom JWT tokens (session_tokens), created with api.redirect.encodeToken. I’ve already modified my initial implementation to use app_metadata instead of sending another session token back to the continue action. However, during this process, I noticed that if you link the original user to another user during the redirect and before the continue redirect, a state sent to continue action can’t be validated because technically, the user doesn’t exist anymore, and their identities are now part of the other user’s identities and I believe this is the root issue. So, if anyone is building a linking logic for the current user where the current user who initiated the redirect has been merged into another user, it will cause issues validating your state when you redirect back to continue. Therefore, you have to perform linking inside the continue action, or probably link verified identity into an initial user who tried to login and not vise-versa like in my case.

1 Like