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
Thank you for this well designed and rational library. My IdP setup, PingID + Azure AD, issues access_tokens with the 'sub' claim. For example, I receive:
The specs on this claim are at odds with one another.
RFC 7519
The “sub” (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The “sub” value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
OpenID Connect Core 1.0
REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.
Can this check be relaxed, or possibly the check made conditional via configuration?
The text was updated successfully, but these errors were encountered:
It's true that we could relax the requirement and make the verification configurable. I will try to add such a feature shortly.
The two specifications that you quote are actually not at odds. The OIDC core spec defines the ID token, and there the sub claim is required. In other JWTs, as defined in RFC 7519, sub is not a required claim (e.g. JWT access tokens do not have to use that claim).
Thank you for this well designed and rational library. My IdP setup, PingID + Azure AD, issues access_tokens with the 'sub' claim. For example, I receive:
This results in the following failure to auth:
The specs on this claim are at odds with one another.
RFC 7519
OpenID Connect Core 1.0
Can this check be relaxed, or possibly the check made conditional via configuration?
The text was updated successfully, but these errors were encountered: