From ad2518bda7da6cb70aa4dba9aca8b79d5cf8f64d Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Fri, 27 Sep 2024 09:06:55 +0300 Subject: [PATCH 1/5] #2109 - confidential client - required for all backchannel requests --- 5.0/en/0x51-V51-OAuth2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index f6db2db895..6715392a82 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -21,7 +21,7 @@ There are various different personas in the OAuth process, described in more det | **51.2.4** | [ADDED] Verify that refresh tokens are sender-constrained or use refresh token rotation to prevent token replay attacks. Refresh token rotation prevents usage in the event of a compromised refresh token. Sender-constrained refresh tokens cryptographically binds the refresh token to a particular Client. | ✓ | ✓ | ✓ | | **51.2.5** | [ADDED] Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) should no longer be used. | ✓ | ✓ | ✓ | | **51.2.6** | [ADDED] Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | ✓ | ✓ | ✓ | -| **51.2.7** | [ADDED] Verify that all confidential clients are authenticated for all token requests to the authorization server. | ✓ | ✓ | ✓ | +| **51.2.7** | [ADDED] Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, PAR requests, token revocation requests, and token introspection requests. | ✓ | ✓ | ✓ | | **51.2.8** | [ADDED] Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | | | ✓ | ## V51.3 OAuth Client From 07a90db823f51ae45dde1ac00433135c7a28fcb7 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Fri, 27 Sep 2024 09:09:24 +0300 Subject: [PATCH 2/5] #2002 - oidc client section and id token replay --- 5.0/en/0x51-V51-OAuth2.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index 6715392a82..c2cdb66d6f 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -42,6 +42,12 @@ There are various different personas in the OAuth process, described in more det | **51.4.2** | [ADDED] Verify that access tokens are restricted to certain resource servers (audience restriction), preferably to a single resource server. Every resource server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular resource server. If not, the resource server must refuse to serve the respective request. | ✓ | ✓ | ✓ | | **51.5.3** | [ADDED] Verify that access tokens are restricted to certain resources and actions on resource servers or resources. Every Resource Server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular action on the particular resource. If not, the resource server must refuse to serve the respective request. | ✓ | ✓ | ✓ | +## V51.5 OIDC Client + +| # | Description | L1 | L2 | L3 | +| :---: | :--- | :---: | :---: | :---: | +| **51.5.1** | [ADDED] Verify that the Client (as the Relying Party) mitigates ID Token replay attacks. For example, by ensuring that the nonce claim in the ID Token matches the nonce value sent in the Authentication Request to the OpenID Provider (in OAuth2 refereed to as the Authorization request sent to the Authorization Server). | ✓ | ✓ | ✓ | + ## Terminology This chapter uses the terms "Access tokens", "Refresh tokens", "Client", "Authorization Server", "Resource Owner", and "Resource Server" as defined by OAuth 2.0 RFC 6749. As such this chapter defines the following terms: From e1e47e5385ca3104dbcf84f933d521b1c6daa5af Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Fri, 27 Sep 2024 20:18:19 +0300 Subject: [PATCH 3/5] #2041 - pkce requirement update --- 5.0/en/0x51-V51-OAuth2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index c2cdb66d6f..3767710bfd 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -17,7 +17,7 @@ There are various different personas in the OAuth process, described in more det | :---: | :--- | :---: | :---: | :---: | | **51.2.1** | [ADDED] Verify that, if the authorization server returns the authorization code, it can be used only once for a token request and it is only valid for up to 10 minutes. | ✓ | ✓ | ✓ | | **51.2.2** | [ADDED] Verify that the replay of authorization codes into the authorization response is prevented either by using the PKCE flow or alternatively the OpenID Connect "nonce" parameter and the respective Claim in the ID Token. The PKCE challenge or OpenID Connect "nonce" must be transaction-specific and securely bound to the client and the user agent in which the transaction was started. | ✓ | ✓ | ✓ | -| **51.2.3** | [ADDED] Verify that, if the code flow is used, the authorization server requires the use of PKCE to mitigate authorization code interception attacks. For authorization requests, the authorization server must require a valid code_challenge value and must only accept code_challenge_method value S256 (plain is not allowed). For a token request, it must require a code_verifier whose value is matching with the code_challenge. | ✓ | ✓ | ✓ | +| **51.2.3** | [ADDED] Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring PKCE. For authorization requests, the authorization server must require a valid code_challenge value and must not accept code_challenge_method 'plain'. For a token request, it must require validation of the "code_verifier" parameter. | ✓ | ✓ | ✓ | | **51.2.4** | [ADDED] Verify that refresh tokens are sender-constrained or use refresh token rotation to prevent token replay attacks. Refresh token rotation prevents usage in the event of a compromised refresh token. Sender-constrained refresh tokens cryptographically binds the refresh token to a particular Client. | ✓ | ✓ | ✓ | | **51.2.5** | [ADDED] Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) should no longer be used. | ✓ | ✓ | ✓ | | **51.2.6** | [ADDED] Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | ✓ | ✓ | ✓ | From 4d9b763dc2dfef2e93c79cc59e782a698eaa5e26 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sat, 28 Sep 2024 18:48:36 +0300 Subject: [PATCH 4/5] #2047 accepted response modes for openid provider --- 5.0/en/0x51-V51-OAuth2.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index 3767710bfd..9791fea61f 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -48,6 +48,12 @@ There are various different personas in the OAuth process, described in more det | :---: | :--- | :---: | :---: | :---: | | **51.5.1** | [ADDED] Verify that the Client (as the Relying Party) mitigates ID Token replay attacks. For example, by ensuring that the nonce claim in the ID Token matches the nonce value sent in the Authentication Request to the OpenID Provider (in OAuth2 refereed to as the Authorization request sent to the Authorization Server). | ✓ | ✓ | ✓ | +## V51.5 OIDC OpenID Provider + +| # | Description | L1 | L2 | L3 | +| :---: | :--- | :---: | :---: | :---: | +| **51.6.1** | [ADDED] Verify that the OpenID Provider only allows values 'code', 'ciba', 'id-token', or 'id-token code' for response mode. Note that 'code' is preferred over 'id-token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) should not be used. | ✓ | ✓ | ✓ | + ## Terminology This chapter uses the terms "Access tokens", "Refresh tokens", "Client", "Authorization Server", "Resource Owner", and "Resource Server" as defined by OAuth 2.0 RFC 6749. As such this chapter defines the following terms: From d787b04c601f288f3a9323822f3ee31f44001bcf Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Mon, 30 Sep 2024 14:59:11 +0300 Subject: [PATCH 5/5] #2110 - update refresh token replay requirement --- 5.0/en/0x51-V51-OAuth2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index 9791fea61f..7245ec8726 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -18,7 +18,7 @@ There are various different personas in the OAuth process, described in more det | **51.2.1** | [ADDED] Verify that, if the authorization server returns the authorization code, it can be used only once for a token request and it is only valid for up to 10 minutes. | ✓ | ✓ | ✓ | | **51.2.2** | [ADDED] Verify that the replay of authorization codes into the authorization response is prevented either by using the PKCE flow or alternatively the OpenID Connect "nonce" parameter and the respective Claim in the ID Token. The PKCE challenge or OpenID Connect "nonce" must be transaction-specific and securely bound to the client and the user agent in which the transaction was started. | ✓ | ✓ | ✓ | | **51.2.3** | [ADDED] Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring PKCE. For authorization requests, the authorization server must require a valid code_challenge value and must not accept code_challenge_method 'plain'. For a token request, it must require validation of the "code_verifier" parameter. | ✓ | ✓ | ✓ | -| **51.2.4** | [ADDED] Verify that refresh tokens are sender-constrained or use refresh token rotation to prevent token replay attacks. Refresh token rotation prevents usage in the event of a compromised refresh token. Sender-constrained refresh tokens cryptographically binds the refresh token to a particular Client. | ✓ | ✓ | ✓ | +| **51.2.4** | [ADDED] Verify that the authorization server mitigates refresh token replay attacks for public clients by using (L1, L2) refresh token rotation or (L1, L2, L3) sender-constrained refresh tokens using Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS). | ✓ | ✓ | ✓ | | **51.2.5** | [ADDED] Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) should no longer be used. | ✓ | ✓ | ✓ | | **51.2.6** | [ADDED] Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | ✓ | ✓ | ✓ | | **51.2.7** | [ADDED] Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, PAR requests, token revocation requests, and token introspection requests. | ✓ | ✓ | ✓ |