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.

[csfreak92]

Yeah, I'm working on the OAuth section on my local copy. I will push commits soon.

[csfreak92]

Question for the leaders: @jmanico, @tghosth, @elarlang, Will OpenID Connect section be under the OAuth 2.0 chapter that we were working on? Or will it be on a separate chapter on its own? If it was the latter part, I would suggest @jsherm-fwdsec to create a PR on a separate branch, but if someone can point him to where to push it so that he won't be waiting too long for me on the OAuth section to be merged.

[elarlang]

At the moment we put all OAuth and OpenID-related requirements into one chapter.

Based on the current direction, we will not have a separate section for OpenID flow. But let's see, how many OpenID-related requirements we will have, we may reorganize them into separate/different chapters.

For current requirement we agreed to add it to the Resource Server chapter:
#1826 (comment)

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)

#1826 (comment)

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.

I can see the procedure, that we get the current OAuth chapter merged to the main branch, and then we go issue-by-issue with the modifications. At the moment it can be a slow-downer, as there are too many "opened issues" as separate comments in different places and it's complicated to get an overview, what is the situation and what must be done.

[jmanico]

I suggest that OAuth2 and OIDC are two separate chapters. They are quite different even though they are both based on the OAuth2 Framework.

[tghosth]

Are they going to be different enough to merit two chapters @csfreak92 ?

[tghosth]

They should probably be in different sections at least

[csfreak92]

I haven't looked at OpenID Connect as closely with OAuth. Maybe separate sections at least for now. Can you draft something for it @jsherm-fwdsec?

[elarlang]

Gentlemen, please, re-read my comment: #1826 (comment) :)

Let's get the OAuth chapter in, let's get the changes done, let's get OIDC requirements in and then we can shake everything to correct or better place if needed. One step at a time.

[jsherm-fwdsec]

Sounds good @elarlang. I'd be happy to help contribute to the OIDC requirements when the time comes.

[TobiasAhnoff]

For OAuth "it depends" so a suggestion is to have a more generic requirement, perhaps like this:

Verify that users and clients can be uniquely identified from the access token. Typically for a JWT by using the iss and sub claims, where subject is a unique identifier for the context of the issuer, but note that other token attributes (claims) can be used as well (depending on context and token format, in example client-id claim).

For OIDC ID Tokens this is given by the specs, see https://openid.net/specs/openid-connect-core-1_0.html#IDToken which states that sub is "A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client...". So the requirement for OIDC could be something like:

Verify that users can be uniquely identified from the ID token, where subject is a unique identifier for the context of the issuer.

[elarlang]

Let's try to get the requirement for "OIDC Client" first. I made some changes to the proposal:

Verify that the Client uniquely identifies the user from ID token claims, where the subject claim is the unique identifier for the issuer context.

ping @TobiasAhnoff @randomstuff

[randomstuff]

Verify that the Client uniquely identifies the user from ID token claims, where the subject claim is the unique identifier for the issuer context.

I think there are two missing things in this formulation:

• the unique identifier might come from another claim;
• what is important is that the identifier is not reassigned.

Therefore, I'd use something like:

Verify that the Client uniquely identifies the user from ID token claim or claims, usually the "sub" claim, which are not reassigned to other users (for the scope of an IdP).

[elarlang]

which are not reassigned to other users (for the scope of an IdP).

"are not reassigned" > "can not be reassigned"?

Verify that the Client uniquely identifies the user from ID token claims, usually the 'sub' claim, which can not be reassigned to other users (for the scope of an IdP).

[elarlang]

The requirement to V51.5 OIDC Client goes in via #2124

#	Description	L1	L2	L3
51.5.2	[ADDED] Verify that the Client uniquely identifies the user from ID token claims, usually the 'sub' claim, which can not be reassigned to other users (for the scope of an identity provider).	✓	✓	✓

[elarlang]

Now, let's move on with the requirement for the OAuth Resource Server:

Verify that users and clients can be uniquely identified from the access token. Typically for a JWT by using the iss and sub claims, where subject is a unique identifier for the context of the issuer, but note that other token attributes (claims) can be used as well (depending on context and token format, in example client-id claim).

We should take into account that the access token information may come from Introspection (https://datatracker.ietf.org/doc/html/rfc7662)

[randomstuff]

Verify that users and clients can be uniquely identified from the access token. Typically for a JWT by using the iss and sub claims, where subject is a unique identifier for the context of the issuer, but note that other token attributes (claims) can be used as well (depending on context and token format, in example client-id claim).

Would it be worth mentioning that this is only if user identification is required (or is that clear enough as it is)? The resource server could very well receive (by design) an anonymous access token.

[elarlang]

Would it be worth mentioning that this is only if user identification is required (or is that clear enough as it is)? The resource server could very well receive (by design) an anonymous access token.

Yes, conditional requirement makes sense.

[TobiasAhnoff]

A suggestion is

Verify that, if authorization is based on user or client identity, users and clients must be uniquely identified from the access token. Typically for a JWT by using the iss and sub claims, where subject is a unique identifier for the context of the issuer, but note that other token attributes (claims) can be used as well (depending on context and token format, in example client-id claim).

Or just

Verify that, if authorization is based on user or client identity, users and clients must be uniquely identified from the access token.

[randomstuff]

@TobiasAhnoff, both wordings use "uniquely identified" which I think is not clear enough (the important feature being "not reattributable").

[randomstuff]

[ADDED] Verify that the Client uniquely identifies the user from ID token claims, usually the 'sub' claim, which can not be reassigned to other users (for the scope of an identity provider).

I am wondering whether it it would be worth adding a requirement stating that if multiple identity providers are used, we should verify that each the identities of each issuer are properly partitioned from each other i.e. that IdP1 cannot spoof the identity of a user from IdP2 (unless this is desired as a consequence of some functional requirement).

[elarlang]

I am wondering whether it it would be worth adding a requirement stating that if multiple identity providers are used, we should verify that each the identities of each issuer are properly partitioned from each other i.e. that IdP1 cannot spoof the identity of a user from IdP2 (unless this is desired as a consequence of some functional requirement).

What if the same user uses 2 different IdP's but those should give the same user in the client?

[elarlang]

For the access token requirement, I propose one alternative direction:

Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that can not be reassigned to other users. Typically it means using a combination of 'iss' and 'sub' claims.

[randomstuff]

What if the same user uses 2 different IdP's but those should give the same user in the client?

Yes, that's why there was "unless this is desired as a consequence of some functional requirement". The goal being to say that this must not happen "by mistake" but only by design. Something in the line of:

Verify that, if multiple identity providers are used by a RP, the identity of a user from an identity provider cannot be spoofed by another identity provider [by using the same user identifier].

[randomstuff]

I am wondering whether it it would be worth adding a requirement stating that if multiple identity providers are used, we should verify that each the identities of each issuer are properly partitioned from each other i.e. that IdP1 cannot spoof the identity of a user from IdP2 (unless this is desired as a consequence of some functional requirement).

On the other hand, this is not specific to OAuth but applicable to other SSO / authentication systems. I'll check which verifications (if any) in the authentication chapter (or somewhere else) already covers this.

[elarlang]

I feel like here are 3 topics mixed:

• requirement 1 - finetuning already added requirement 51.5.2 (Add requirement about usage of claims other than subject and issuer as an identifier for OpenID Connect #1826 (comment))
• requirement 2 - developing new requirement proposed in Add requirement about usage of claims other than subject and issuer as an identifier for OpenID Connect #1826 (comment)
• requirement 3 - opening wider topic for identifying the user

I there is need to improve requirement 1, let's open a new issue.

Let's have agreement - PR-ready for requirement 2.

If there is material for requirement 3, it is material for a separate issue.

[elarlang]

The second requirement goes to V51.4 OAuth Resource Server via #2140

#	Description	L1	L2	L3
51.4.4	[ADDED] Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that can not be reassigned to other users. Typically it means using a combination of 'iss' and 'sub' claims.	✓	✓	✓

[elarlang]

We have now two requirements in, but feels like one topic requires some spin-off from here.

@randomstuff - please recheck it, and if the "user idenfitication" issue requires a separate issue, please open it.

[elarlang]

We have now two requirements in, but feels like one topic requires some spin-off from here.

@randomstuff - please recheck it, and if the "user idenfitication" issue requires a separate issue, please open it.

It has it's own issue now: #2150 and we can close this one out.