Add requirement about usage of claims other than subject and issuer as an identifier for OpenID Connect

[jsherm-fwdsec]

Usage of claims other than the subject and issuer identifier to uniquely identify an end user in OpenID Connect is non-compliant with the framework. As per a recent Microsoft report, there is a false identifier anti-pattern being followed and exploited in the wild resulting in account takeover.

To keep it simple, the sub (subject) and iss (issuer) claims, when used together, are considered to be a unique primary identifier for OIDC, as the uniqueness across users is guaranteed. Other claims such as email, username or phone number should not be used, as they can change over time and an attacker can falsify these claims.

I'm interested in contributing and happy to create a PR for this, as well as adding other OIDC requirements. Perhaps this is something I can help with as part of the OAuth2 changes being discussed here ?

[jmanico]

Super excited about this. A dedicated OIDC section would be fantastic!

[elarlang]

Yes, that is correct - we have OAuth PR to be discussed and merged and that is why we don't have sepparate issues per requirement so far on the topic.

The branch for that is located at https://github.com/OWASP/ASVS/blob/master-v51-oauth/5.0/en/0x51-V51-OAuth2.md

If you have in mind some wording for the proposed requirement, please share it that (we can fine-tune and help with that) and matching section from the OAuth category.

[ImanSharaf]

@jsherm-fwdsec great idea!

[tghosth]

@csfreak92 did you see this? Can you work with @jsherm-fwdsec on this?

[csfreak92]

For sure @tghosth, will work with @jsherm-fwdsec on this one! I think some parts of it were covered by OAuth 2.0 requirements that I wrote, but I will double/triple check to ensure we got them nailed to good detail to include OpenID stuff.

[elarlang]

I'm interested in contributing and happy to create a PR for this

our usual process is, that we first have agreement on the requirement wording in an issue and then we go for PR. This way it is easier to follow later, why some change was made and what where the arguments behind the change were.

@jsherm-fwdsec - do you have a wording or an idea for the point for additional requirement(s)?

[jmanico]

How about… Verify that applications utilizing OpenID Connect identify and utilize at least one additional claim, beyond `sub` and `iss`. This could include claims such as `email`, `preferred_username`, or a custom claim agreed upon with the identity provider (IdP).

[elarlang]

How about… Verify that applications utilizing OpenID Connect identify and utilize at least one additional claim, beyond sub and iss. This could include claims such as email, preferred_username, or a custom claim agreed upon with the identity provider (IdP).

For me it seems it is not correct, see https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability.

Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.

[jsherm-fwdsec]

Hi @jmanico @elarlang! Agreed I think we need to be more specific about what the unique identifier should be and it should conform to the spec.

How about something such as this:
Verify that the unique identifier in the ID token for an end-user is a combination of the sub Claim and the iss Claim. Avoid usage of other claims such as email, phone_number, preferred_username, or name , as they may be mutable and can be potentially falsified.

[elarlang]

• should it be conditional? "if unique identifier for an end-user is needed or used"
• category/section choice - does it fit to the "Resource Server" (as "Relying Party") section in our current structure (https://github.com/OWASP/ASVS/blob/master-v51-oauth/5.0/en/0x51-V51-OAuth2.md)

[jsherm-fwdsec]

That works here's what I would suggest:
Verify that the unique identifier in the ID/access token for an end-user is a combination of the sub claim and the iss claim, if a unique identifier is needed. Avoid usage of other claims such as email, phone_number, preferred_username, or name , as they may be mutable and can be potentially falsified.

Also agreed this should go under https://github.com/OWASP/ASVS/blob/master-v51-oauth/5.0/en/0x51-V51-OAuth2.md#v513-resource-server.

Since we're touching on ID tokens that are specific to OIDC, we might also want to add and update some terminology under this section for ID token, access token, and "Authorization Server" to include info about the OpenID Provider: https://github.com/OWASP/ASVS/blob/master-v51-oauth/5.0/en/0x51-V51-OAuth2.md#terminology.

Here's my attempt:

• ID tokens - These are issued by an OpenID Provider (OP) and contain a set of claims (assertions) about the authentication event. These tokens are represented as JSON Web Tokens (JWTs), which means they are compact, URL-safe, and contain a payload of claims encoded in JSON format. The claims in an ID token typically include information about the user (such as the user's identifier), information about the token's validity period, and information about the authentication event (such as the time of authentication and the method used). ID tokens are intended for the client that initiates the authentication request. The client can validate the ID token to ensure that it was issued by the expected OpenID Provider and that the authentication event meets the client's requirements.
• Access tokens - Access tokens are used to access protected resources. They are issued by an authorization server and are sent to an API or resource server to authorize access to a resource. Unlike ID tokens, access tokens are not necessarily intended to be understood by the client. They can be opaque strings or JWTs that represent the authorization granted to the client by the resource owner. The format and content of access tokens are typically intended for the resource server and are not standardized in the same way as ID tokens. Access tokens have a limited lifetime and scope, which means they grant temporary access to a specific set of resources with defined permissions. The resource server must validate the access token to ensure it is valid, has not expired, and grants the required permissions for the requested resource.
• Authorization Server (AS) - This refers to the server issuing ID/access tokens to the client after successfully authenticating the resource owner and obtaining authorization. For OpenID Connect (OIDC) flows, this is sometimes also referred to as the OpenID Provider (OP) or Identity Provider (IdP) in certain cases, especially when the service is designed to provide both authentication and authorization functionality as part of a single platform. This combination is common in many implementations of OAuth 2.0 and OIDC.

[elarlang]

Just for info, we need to solve some other open issues for the OAuth paragraph before moving this one further.