From 849c7eae1cfbe55bb46da6976933bf1618c79665 Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Wed, 23 Oct 2024 19:03:52 +0300 Subject: [PATCH 1/3] #2092 - general requirement for 'transaction-specific' --- 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 505690d1d8..2ca37a7143 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -10,6 +10,7 @@ There are various different personas in the OAuth process, described in more det | :---: | :--- | :---: | :---: | :---: | | **51.1.1** | [ADDED] Verify that tokens (such as ID tokens, access tokens and refresh tokens) can only be used for their intended purpose. For example, ID tokens can only be used to prove user authentication for the client. | ✓ | ✓ | ✓ | | **51.1.2** | [ADDED] Verify that tokens are only sent to components that strictly need them. For example, avoid having access or refresh tokens accessible for the frontend when they are only needed by the backend. | ✓ | ✓ | ✓ | +| **51.1.3** | [ADDED] Verify that the client accepts the values (such as the authorization code or ID token) from the authorization server only if these result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce' are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | ✓ | ✓ | ✓ | ## V51.2 OAuth Authorization Server @@ -29,7 +30,6 @@ There are various different personas in the OAuth process, described in more det | **51.2.12** | [ADDED] Verify that for a given client, an attacker may not tamper with the 'response_mode' parameter, for example by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured authorization request (JAR). | ✓ | ✓ | ✓ | | **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. | ✓ | ✓ | ✓ | -| **51.2.15** | [ADDED] Verify that the replay of authorization codes into the authorization response is prevented either by using the proof key for code exchange (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. | ✓ | ✓ | ✓ | ## V51.3 OAuth Client From 63781e837ef3dca9f4176a58200337bde3b6f76c Mon Sep 17 00:00:00 2001 From: Elar Lang Date: Wed, 23 Oct 2024 19:31:56 +0300 Subject: [PATCH 2/3] oauth and oidc references, related to #2036 and #2037 --- 5.0/en/0x51-V51-OAuth2.md | 36 ++++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/5.0/en/0x51-V51-OAuth2.md b/5.0/en/0x51-V51-OAuth2.md index 2ca37a7143..5fc75724b0 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -92,6 +92,7 @@ The Resource Owner refers to an entity capable of granting access to a protected The Resource Server refers to the server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. + -## OAuth 2.0 References +## References -For more information, see also: +For more information on OAuth, please see: -* RFC 6749 - The OAuth 2.0 Authorization Framework: -* RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage: -* OAuth 2.0 Best Practices: -* Mix-up attacks: -* RFC9207 - OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response: -* Other Countermeasures for Mix-up attacks: +* [oauth.net](https://oauth.net/) +* [OWASP Cheat Sheet: OAuth 2.0 Protocol Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) + +For OAuth-related requirements in ASVS following published and in draft status RFC-s are used: + +* [RFC6749 The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +* [RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750) +* [RFC6819 OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819) +* [RFC7636 Proof Key for Code Exchange by OAuth Public Clients](https://datatracker.ietf.org/doc/html/rfc7636) +* [RFC9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://datatracker.ietf.org/doc/html/rfc9068) +* [RFC8628 OAuth 2.0 Device Authorization Grant](https://datatracker.ietf.org/doc/html/rfc8628) +* [RFC8707 Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707) +* [RFC9126 OAuth 2.0 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126) +* [RFC9207 OAuth 2.0 Authorization Server Issuer Identification](https://datatracker.ietf.org/doc/html/rfc9207) +* [RFC9396 OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396) +* [RFC9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449) +* [draft OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) +* [draft OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) +* [draft The OAuth 2.1 Authorization Framework](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11) + +For more information on OpenID Connect, please see: + +* [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) +* [FAPI 2.0 Security Profile](https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html) From 22f991879a6235c0c6f450735cec8eca4003e84c Mon Sep 17 00:00:00 2001 From: Josh Grossman Date: Thu, 24 Oct 2024 22:17:56 +0300 Subject: [PATCH 3/3] Wording tweal --- 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 5fc75724b0..83cccb7dc2 100644 --- a/5.0/en/0x51-V51-OAuth2.md +++ b/5.0/en/0x51-V51-OAuth2.md @@ -10,7 +10,7 @@ There are various different personas in the OAuth process, described in more det | :---: | :--- | :---: | :---: | :---: | | **51.1.1** | [ADDED] Verify that tokens (such as ID tokens, access tokens and refresh tokens) can only be used for their intended purpose. For example, ID tokens can only be used to prove user authentication for the client. | ✓ | ✓ | ✓ | | **51.1.2** | [ADDED] Verify that tokens are only sent to components that strictly need them. For example, avoid having access or refresh tokens accessible for the frontend when they are only needed by the backend. | ✓ | ✓ | ✓ | -| **51.1.3** | [ADDED] Verify that the client accepts the values (such as the authorization code or ID token) from the authorization server only if these result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce' are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | ✓ | ✓ | ✓ | +| **51.1.3** | [ADDED] Verify that the client only accepts values from the authorization server (such as the authorization code or ID token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce' are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | ✓ | ✓ | ✓ | ## V51.2 OAuth Authorization Server