id_token claims should be decoded before afterCallback is invoked

[nboisnea]

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

[kushalshit27]

Thanks for the feature request! We will evaluate how to incorporate it. 🤝

[aks96]

This is about whether afterCallback should provide decoded Id_token automatically. This would be API design change. It probably changes the expected behaviour of SDK API.
The current SDK behaviour returns the raw id_token to afterCallback and proposal suggest automatically decoding and exposing the token claims. We need more view on this to understand more of its use-case and how helpful it will in those.
It could be breaking change also so need more clarity on compatibility expectations.