From 9148cf5a1affe325814ffd2e5025f0bc17804328 Mon Sep 17 00:00:00 2001 From: Josh Grossman Date: Wed, 18 Sep 2024 08:32:03 +0300 Subject: [PATCH] Minor wording tweaks --- 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 53035ae11..fd064503a 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 request, authorization server requires valid code_challenge value and accepts code_challenge_method value S256 (plain is not allowed). For token request it requires code_verifier with value calculated from code_challenge. | ✓ | ✓ | ✓ | +| **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 acode_verifier whose value is calculated from the code_challenge. | ✓ | ✓ | ✓ | | **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 the Resource Owner password credentials grant is not used or configured by the Authorization Server. This grant type insecurely exposes the credentials of the Resource Owner to the client, increasing the attack surface of the application. | ✓ | ✓ | ✓ | | **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. | ✓ | ✓ | ✓ |