proposal/discussion: OAuth - (for 1st party usage) only used (by the client) communication options must be allowed by authorization server

[elarlang]

spin-off from https://github.com/OWASP/ASVS/issues/1916 "Discussion/Proposal 2"

For a situation, where OAuth is used as a "first-party" authorization solution and the application needs one and only way how it communicates with the authorization server, then for the OAuth client must be configured and the Authorization Server must validate, that: only the expected values are allowed, that is implemented by the client:

• response_type
• response_mode
• scope - here, support for the offline_access may be worth special mention

edit: scope in mind - authorization request from OAuth Client to OAuth Authorization Server

-- Feedback from @tghosth in https://github.com/OWASP/ASVS/issues/1916#issuecomment-2024985876

If this is a simple requirement then it sounds sensible as long as it is not too detailed.

-- Overlap by recommendation from @TobiasAhnoff in https://github.com/OWASP/ASVS/issues/1925

3 Verify that client configuration asserts least privilege (e g scopes and flows)

Although response_type and response_mode are not directly privilege, those are all related with allowed flow.

[elarlang]

3 Verify that client configuration asserts least privilege (e g scopes and flows)

I was thinking more about it - I think it is another topic compared which I opened, so probably we have 2 different vectors to cover.

• original issue - (at least for 1st party solution) authorization server should accept only those parameters and values for communication, that are needed by the (one and only) OAuth Client - response_mode, response_type, scope
• additional issue, by Tobias - scope definition on the Authorization Server side for the OAuth Client should not give more permissions than needed for given client and actions.

ping @TobiasAhnoff - please confirm my understanding

[jmanico]

Based on the typical OAuth registration and "user" workflow, I would add one more level here.

1) Server allows a series of scopes to start with. 2) Client registers (once) with a limited list of these scopes (or all that the server offers). 3) A "user" goes through the OAuth flow and may only use the scopes that the server approved of during registration time and NOT NECESSARILY the complete lists of scopes that server allows. Again, only the scope the server approved of during client registration should be allowed during user flows, and I feel we need to clarify that level of strictness.

So I'd suggest two requirements around scopes since there are granted at very different parts of the OAuth lifecycle.

1) Only let a client register for scopes that the server allows 2) Only let a "user" use scopes the authorization server approved of during client-registration

[elarlang]

I'm not sure we are talking about the same thing here (user registration vs configured client), I modified initial issue to be more clear and added:

edit: scope in mind - authorization request from OAuth Client to OAuth Authorization Server

For the 1st party solution (if there is no "discovery" in place), when an application uses the SSO service from the same organization, there should be no client registration available for being a OAuth Client. It is actually worth a separate requirement.

[TobiasAhnoff]

A suggestion is to add something like this:

L1,L2,L3: Verify that allowed scopes for each client asserts least privilege (especially if RS authorization is based on just a valid token and scopes, not using any additional token claims like identity of the caller or group membership)

L2,L3: Verify that all clients are configured to only allow the required flow. For system integrations only allow grant type 'client-credentials' and for user interaction applications only allow grant type 'code' (Implicit and ROPC should not be supported, other additional flows like Device Authorization Grant might be supported if needed). Avoid reusing clients for different purposes (allowing e g both code and client-credentials).

L1,L2,L3: Verify that grant type 'code' is always used together with PKCE

L3: "Verify that all clients are confidential" (L1-L2 could allow for public clients)

L3: "Verify that all clients are configured to use strong client authentication, mTLS or private-key-jwt" (L1-L2 could also use client-secret, note that verification 9.3.3 mandates mTLS, but private-key-jwt is also regarded sufficient by e g FAPI)

L3: Verify that PAR with client authentication is used (for L1-L2 PAR is optional and could be used without client authentication)

L3: Verify that sender-constrained access-tokens are used either using mTLS or DPoP (note that for L1 and L2 this does not require client authentication if used by public clients)

L3: Verify that refresh-tokens are sender-constrained (by requiring client authentication for all token requests, while L1-L2 could allow one-time mitigation strategy for public clients, this is especially important if offline_access is granted, allowing long lived tokens not attached to active user sessions)