Adding OAuth 2.1 specifications #1971
Conversation
Update 0x51-V51-OAuth2.md based on recommendations from reviewers to reflect OAuth 2.1 specifications and comments from reviewers.
| @@ -14,15 +14,17 @@ There are various different personas in the OAuth process, described in more det | |||
| | **51.1.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.1.5** | [ADDED] Verify that if a Client sends a valid PKCE "code_challenge" parameter in the authorization request, the Authorization Server enforces the correct usage of "code_verifier" at the token endpoint. | ✓ | ✓ | ✓ | | |||
| | **51.1.6** | [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.1.7** | [ADDED] Verify that the Authorization Server does not expose URLs that forward the user's browser to arbitrary URIs obtained from a query parameter ("open redirectors") which can enable exfiltration of authorization codes and access tokens. Redirect URIs must be compared using exact string-matching. | ✓ | ✓ | ✓ | | |||
There was a problem hiding this comment.
"Redirect URIs must be compared using exact string-matching.": Should this not be a separate requirement ?
There was a problem hiding this comment.
Do you mean the second sentence to be separated and create another requirement than them both being in one requirement?
There was a problem hiding this comment.
@csfreak92: Yes. This looks like quite unrelated things to me.
There was a problem hiding this comment.
As I read it, the first part is "do not have an open-redirect vulnerability" on the authorization server (covered by 5.1.5):
The second part is for the string-match method, end would be covered by the outcome from #1965 (comment)
There was a problem hiding this comment.
Ah so we should just drop the open-redirect in this requirement and retain the string-match method. Gotcha, I can fix that, but let's wait for the result of that thread's comment. :)
|
Hi, I wrote my comment in #1965 In short, let's have an agreement on proposed requirement text before we do PR. I close this for now. |
|
Note, I reopened it at the moment. First I thought it was only about the one redirect_uri requirement, but there were more changes in. |
|
Hi Elar, noted. |
| @@ -82,7 +84,7 @@ Restricting token privileges ensures a Client is granted the proper access to a | |||
|
|
|||
| ### Resource Owner Password Credentials Grant | |||
|
|
|||
| Aside from this grant type can leak credentials in more places than just the Authorization Server, adapting the Resource Owner password credentials grant to two-factor authentication, authentication with cryptographic credentials (e.g. WebCrypto, WebAuthn) and authentication processes that require multiple steps can be hard or impossible. | |||
| Aside from this grant type can leak credentials in more places than just the Authorization Server, adapting the Resource Owner password credentials grant to two-factor authentication, authentication with cryptographic credentials (e.g. WebCrypto, WebAuthn) and authentication processes that require multiple steps can be hard or impossible. This grant type is not recommended in general due to security concerns. Instead, use the authorization code grant with PKCE. This grant type is omitted from OAuth 2.1 specification. | |||
There was a problem hiding this comment.
Instead, use the authorization code grant with PKCE. This grant type is omitted from OAuth 2.1 specification.
Is it me or might this be interpreted as "authorization code grant with PKCE is omitted from OAuth 2.1"?
There was a problem hiding this comment.
Maybe swap the two sentences?
There was a problem hiding this comment.
Hi @randomstuff, great catch! Now that I read it a few times, it makes sense to swap the positioning of sentences. I'll update this PR as well for this.
| @@ -68,7 +70,7 @@ In OpenID Connect flows, the "nonce" parameter provides CSRF protection. Otherwi | |||
|
|
|||
| OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. Proof Key for Code Exchange (PKCE, pronounced "pixy") is the technique used to mitigate against the threat of authorization code interception attack. | |||
|
|
|||
| Originally, PKCE is intended to be used solely focused on securing native apps, but then it became a deployed OAuth feature. It does not only protect against authorization code injection attacks, but also protects authorization codes created for public clients as PKCE ensures that the attacker cannot redeem a stolen authorization code at the token endpoint of the authorization server without knowledge of the code_verifier. | |||
| Originally, PKCE is intended to be used solely focused on securing native apps, but then it became a deployed OAuth feature. It does not only protect against authorization code injection attacks, but also protects authorization codes created for public clients as PKCE ensures that the attacker cannot redeem a stolen authorization code at the token endpoint of the authorization server without knowledge of the code_verifier. | |||
There was a problem hiding this comment.
@csfreak92 the way the second sentence reads to me here sort of implies that an attacker can do something other than an authorization code injection attack, if they get ahold of the authorization code.
Suggestion to rework this paragraph to something such as this:
PKCE, initially designed to secure native apps, has evolved into a widely adopted OAuth feature even for web applications. It safeguards authorization codes for both public and confidential clients by ensuring that even if a code is stolen, it can't be redeemed at the authorization server's token endpoint without the corresponding code_verifier.
| @@ -68,7 +70,7 @@ In OpenID Connect flows, the "nonce" parameter provides CSRF protection. Otherwi | |||
|
|
|||
| OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. Proof Key for Code Exchange (PKCE, pronounced "pixy") is the technique used to mitigate against the threat of authorization code interception attack. | |||
|
|
|||
| Originally, PKCE is intended to be used solely focused on securing native apps, but then it became a deployed OAuth feature. It does not only protect against authorization code injection attacks, but also protects authorization codes created for public clients as PKCE ensures that the attacker cannot redeem a stolen authorization code at the token endpoint of the authorization server without knowledge of the code_verifier. | |||
| Originally, PKCE is intended to be used solely focused on securing native apps, but then it became a deployed OAuth feature. It does not only protect against authorization code injection attacks, but also protects authorization codes created for public clients as PKCE ensures that the attacker cannot redeem a stolen authorization code at the token endpoint of the authorization server without knowledge of the code_verifier. | |||
There was a problem hiding this comment.
Originally, PKCE is intended to be used solely focused on securing native apps, but then it became a deployed OAuth feature.
Should this be “Originally, PKCE was intended”?
|
So the requirement got into the repo and now there is opened some discussion over chapter texts (2 lines). I prefer we have a clear understanding of an issue before we go for PR and do not have discussion over them in the PR's. |
|
I close it now. Please see and follow: #996 (comment) |
Update 0x51-V51-OAuth2.md based on recommendations from reviewers to reflect OAuth 2.1 specifications and comments from reviewers.
This Pull Request relates to issue #996 by taking into consideration the initial wave of recommendations.