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
Per the OpenID Connect specification, the at_hash claim in ID Token can be optional, depending on circumstance. Thus, I'd expect ID token validation to succeed when the at_hash ID cliam is not required and not provided.
This was the actual behavior up to social-core 4.4.2.
Actual behaviour
Since social-core version 4.5, the OpenIdConnectAuth backend incorrectly raises an AuthTokenError when the Authorization Code flow is used without the use of the at_hash claim in an ID token.
What are the steps to reproduce this issue?
Input clear steps to reproduce the issue for a maintainer.
Use the OpenIdConnectAuth backend with the codeRESPONSE_TYPE.
Make a request to a ID provider which does not include an at_hash claim in the ID token, such as Auth0.com.
Error occurs upon ID token validation.
Any logs, error output, etc?
The problematic code in question is here. This check should succeed when at_hash is not in the claim set, as is the behavior in the original python-josefunctionality.
Any other comments?
The text was updated successfully, but these errors were encountered:
Expected behaviour
Per the OpenID Connect specification, the
at_hash
claim in ID Token can be optional, depending on circumstance. Thus, I'd expect ID token validation to succeed when theat_hash
ID cliam is not required and not provided.This was the actual behavior up to social-core 4.4.2.
Actual behaviour
Since social-core version 4.5, the
OpenIdConnectAuth
backend incorrectly raises anAuthTokenError
when the Authorization Code flow is used without the use of theat_hash
claim in an ID token.What are the steps to reproduce this issue?
Input clear steps to reproduce the issue for a maintainer.
OpenIdConnectAuth
backend with thecode
RESPONSE_TYPE
.at_hash
claim in the ID token, such as Auth0.com.Any logs, error output, etc?
The problematic code in question is here. This check should succeed when
at_hash
is not in the claim set, as is the behavior in the originalpython-jose
functionality.Any other comments?
The text was updated successfully, but these errors were encountered: