Merge OAuth chapter into master

[tghosth]

This Pull Request relates to issue #996.

For now, this is just to monitor the "mergability" of the changes. We won't actually merge this until it has finished the development process.

[tghosth]

Note some original comments were raised here:
#1494 (review)

[elarlang]

51.1.5 - I don't think we can/need to require it. It is recommended as one way to do that.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-authorization-code-grant
It is RECOMMENDED for AS to publish the element code_challenge_methods_supported in their AS metadata ([RFC8414]) containing the supported PKCE challenge methods (which can be used by the client to detect PKCE support). ASs MAY instead provide a deployment-specific way to ensure or determine PKCE support by the AS.

51.4.1 - We can not have requirements for the Resource Owner (end-user). Is a certain flow or grant is accepted/supported, it is the Authorization Server's responsibility to configure it for the OAuth Client. So it belongs to the "Authorization Server" section.

This is for a quick fix. But... as I opened a discussion in #996 (comment), maybe we should not list the grants/flows which are not allowed per requirement, but have one requirement to say "Use the PKCE flow and X only, which also means, y z w flows are not allowed."

[tghosth]

hi @csfreak92, are you still clear on the remaining feedback that needs to be actioned here. It would be great to get a first draft of this chapter merged into master.

[csfreak92]

Yes @tghosth, still working on it in my local copy first before pushing a commit. I will push a commit soon around late next week after this week's madness. :)

[tghosth]

@csfreak92 please do the following:

• Review my changes here to make sure you are comfortable with them: 4821e90
  • I removed 5.1.5 as per Elar's comment Merge OAuth chapter into master #1804 (comment) which I agree with.
  • Removed the link in a requirement as it appears in the references at the end.
• As per Elar's comment here: Merge OAuth chapter into master #1804 (comment) about 51.4.1 - We can not have requirements for the Resource Owner (end-user). Is a certain flow or grant is accepted/supported, it is the Authorization Server's responsibility to configure it for the OAuth Client. So it belongs to the "Authorization Server" section. - I agree, please open a PR to address this.
• Please answer my question here: Merge OAuth chapter into master #1804 (comment)

[jmanico]

I also have one suggestion:

For...

+| 51.3.1 | [ADDED] Verify that Resource Servers are using mechanisms for sender-constraining access tokens to prevent token replay, such as Mutual TLS for OAuth 2.0 or OAuth Demonstration of Proof of Possession (DPoP). | ✓ | ✓ | ✓ |

... you are supposed to use the same client secret given to the client during registration. This implied it's arbitrary. My edit suggestion is:

+| 51.3.1 | [ADDED] "Verify Resource Servers implement sender-constrained access token mechanisms to mitigate token replay risks. This is achieved by mandating Mutual TLS for OAuth 2.0 or OAuth DPoP, using the client secret provided at client registration.". | ✓ | ✓ | ✓ |

[csfreak92]

... you are supposed to use the same client secret given to the client during registration. This implied it's arbitrary. My edit suggestion is:

+| 51.3.1 | [ADDED] "Verify Resource Servers implement sender-constrained access token mechanisms to mitigate token replay risks. This is achieved by mandating Mutual TLS for OAuth 2.0 or OAuth DPoP, using the client secret provided at client registration.". | ✓ | ✓ | ✓ |

Noted, @jmanico. Just as I mentioned in the other comment, I thought of explicitly calling it out as some people might not think it is implied already, but for brevity I agree with this assessment :)

[csfreak92]

This is for a quick fix. But... as I opened a discussion in #996 (comment), maybe we should not list the grants/flows which are not allowed per requirement, but have one requirement to say "Use the PKCE flow and X only, which also means, y z w flows are not allowed."

Oh sorry Elar, I thought I addressed this already. I will fix it in my new PR that I was asked to open.

[tghosth]

@elarlang @jmanico let's get this approved and then we can see what other comments we have on it

[elarlang]

Let's get it merged to have it in the spotlight to get more attention.