You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 7, 2020. It is now read-only.
In handler, why access-token is verified and used instead of id-token itself for OpenID. Shouldn't id-token be verified primarily in OpenIDC.
Comment snippet from code : // Flow: once we exchange the authorization code we parse the ID Token; we then check for an access token, // if an access token is present and we can decode it, we use that as the session token, otherwise we default // to the ID Token.
I can see in code that it falls back to id-token only if access-token is not available.
I'm trying to understand the reason for the same here.
The text was updated successfully, but these errors were encountered:
but there will be still problem with verifying access token in middleware, because right now it uses verifytoken method for id token and thus also checks client_id=aud which may/may not be true so it shouldn't be checked by default, but it can't be turned off
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In handler, why access-token is verified and used instead of id-token itself for OpenID. Shouldn't id-token be verified primarily in OpenIDC.
Comment snippet from code :
// Flow: once we exchange the authorization code we parse the ID Token; we then check for an access token, // if an access token is present and we can decode it, we use that as the session token, otherwise we default // to the ID Token.
I can see in code that it falls back to id-token only if access-token is not available.
I'm trying to understand the reason for the same here.
The text was updated successfully, but these errors were encountered: