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.
Checklist
Describe the problem you'd like to have solved
In the
afterCallbackthat can be set inauth's configuration, we only have access to the plain session data, including the non-decoded, but already validated, id_token. Also, everything in thereq.oidcobject 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 inreq.oidc? Or passed toafterCallbackin some way?Describe the ideal solution
ID token should be decoded, and the
oidcobject populated beforeafterCallbackis 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