From a137ff17efcad6036a3ce00868040bd9c54ef367 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sat, 12 Oct 2024 18:09:05 +0300 Subject: [PATCH 1/5] #1964 - limit response_mode values for the client by AS --- 5.0/en/0x51-V51-OAuth2.md | 1 + 1 file changed, 1 insertion(+) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index 878799f2c3..d66eb0af30 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -26,6 +26,7 @@ There are various different personas in the OAuth process, described in more det | **51.2.9** | [ADDED] Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | | | ✓ | | **51.2.10** | [ADDED] Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), i. e. 'mTLS' or 'private-key-jwt'. | | | ✓ | | **51.2.11** | [ADDED] Verify that the authorization server issues only sender-constrained (Proof-of-Posession) access tokens, either using mTLS certificate binding or Demonstration of Proof of Possession (DPoP). | | | ✓ | +| **51.2.12** | [ADDED] Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. | ✓ | ✓ | ✓ | ## V51.3 OAuth Client From 9e8c013799cadabb01587e7c245b2385e2e9444e Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sat, 12 Oct 2024 18:12:50 +0300 Subject: [PATCH 2/5] #1968 - max lifetime for refresh tokens --- 5.0/en/0x51-V51-OAuth2.md | 1 + 1 file changed, 1 insertion(+) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index d66eb0af30..a800d9c5da 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -27,6 +27,7 @@ There are various different personas in the OAuth process, described in more det | **51.2.10** | [ADDED] Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), i. e. 'mTLS' or 'private-key-jwt'. | | | ✓ | | **51.2.11** | [ADDED] Verify that the authorization server issues only sender-constrained (Proof-of-Posession) access tokens, either using mTLS certificate binding or Demonstration of Proof of Possession (DPoP). | | | ✓ | | **51.2.12** | [ADDED] Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. | ✓ | ✓ | ✓ | +| **51.2.13** | [ADDED] Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | ✓ | ✓ | ✓ | ## V51.3 OAuth Client From 57f3303087afb7bde34dfd63e513289ef4c4f496 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sat, 12 Oct 2024 18:19:38 +0300 Subject: [PATCH 3/5] #2111 - support revoke tokens --- 5.0/en/0x51-V51-OAuth2.md | 1 + 1 file changed, 1 insertion(+) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index a800d9c5da..49eba53e80 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -28,6 +28,7 @@ There are various different personas in the OAuth process, described in more det | **51.2.11** | [ADDED] Verify that the authorization server issues only sender-constrained (Proof-of-Posession) access tokens, either using mTLS certificate binding or Demonstration of Proof of Possession (DPoP). | | | ✓ | | **51.2.12** | [ADDED] Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. | ✓ | ✓ | ✓ | | **51.2.13** | [ADDED] Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | ✓ | ✓ | ✓ | +| **51.2.14** | [ADDED] Verify that refresh tokens and reference access tokens can be revoked by an authorized user. It can be achieved by using the authorization server user interface, or by a client that is using authorization server APIs for revocation. | ✓ | ✓ | ✓ | ## V51.3 OAuth Client From bc47fe219d3531b9f5b6b47bfd8abc4a0dba318d Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sat, 12 Oct 2024 18:23:41 +0300 Subject: [PATCH 4/5] #1826 - detecting unique user from access token --- 5.0/en/0x51-V51-OAuth2.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index 49eba53e80..b0e3304b5f 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -47,7 +47,8 @@ There are various different personas in the OAuth process, described in more det | :---: | :--- | :---: | :---: | :---: | | **51.4.1** | [ADDED] Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP). | | | ✓ | | **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. | ✓ | ✓ | ✓ | +| **51.4.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. | ✓ | ✓ | ✓ | +| **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. | ✓ | ✓ | ✓ | ## V51.5 OIDC Client From fa8504462237b2ceb5c97b6283db5e0b07d90c12 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Sat, 12 Oct 2024 18:25:34 +0300 Subject: [PATCH 5/5] #2110 - specify refresh token rotation --- 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 b0e3304b5f..7f28ea0cb6 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 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.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). If refresh token rotation is used, verify that the authorization server invalidates the refresh token after usage and revokes all refresh tokens for that authorization if an already used and invalidated refresh token is provided. | ✓ | ✓ | ✓ | | **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. | ✓ | ✓ | ✓ |