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

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 ?

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

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.

@jsherm-fwdsec

@jsherm-fwdsec great idea!

@csfreak92

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

@tghosth

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.

@jsherm-fwdsec

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)?

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).

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.

@jmanico

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.

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)

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.

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

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?

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.

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].

#1826 - unique user identification from an ID Token

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.

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.

OWASP#1826 - detecting unique user from access token

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.	✓	✓	✓

#1826 - detecting unique user from access token

@randomstuff

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.

@randomstuff

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.

Navigation Menu

Repository navigation

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

43 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

jmanico commented on Jan 17, 2024

elarlang commented on Jan 17, 2024

ImanSharaf commented on Jan 17, 2024

tghosth commented on Jan 24, 2024

csfreak92 commented on Jan 30, 2024

elarlang commented on Feb 8, 2024

jmanico commented on Feb 8, 2024

elarlang commented on Feb 9, 2024

jsherm-fwdsec commented on Feb 9, 2024

elarlang commented on Feb 10, 2024

jsherm-fwdsec commented on Feb 13, 2024

elarlang commented on Feb 15, 2024

43 remaining items

elarlang commented on Oct 8, 2024

elarlang commented on Oct 8, 2024

randomstuff commented on Oct 8, 2024

randomstuff commented on Oct 8, 2024

elarlang commented on Oct 9, 2024

elarlang commented on Oct 12, 2024

elarlang commented on Oct 13, 2024

elarlang commented on Oct 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions