Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

id_token claims should be decoded before afterCallback is invoked #634

Open
5 tasks done
nboisnea opened this issue Oct 18, 2024 · 0 comments
Open
5 tasks done

id_token claims should be decoded before afterCallback is invoked #634

nboisnea opened this issue Oct 18, 2024 · 0 comments

Comments

@nboisnea
Copy link

Checklist

  • I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
  • I have looked into the API documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

In the afterCallback that can be set in auth's configuration, we only have access to the plain session data, including the non-decoded, but already validated, id_token. Also, everything in the req.oidc object is undefined. This example shows how to manually retrieve claims from the id_token using Jose (or any other lib).
Since the id_token will end up being decoded anyways, wouldn't it be better if the id_token's claims were already decoded and set in req.oidc? Or passed to afterCallback in some way?

Describe the ideal solution

ID token should be decoded, and the oidc object populated before afterCallback is invoked. This would avoid decoding the token twice. Whatever could be done with the id_token in the callback previously can still be achieved. Some use case which required decoding the token in the callback may be simplified.

Alternatives and current workarounds

No response

Additional context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant