V51 OAuth: discuss verification of the user consent

[randomstuff]

In OAuth / OpenID Connect, checking of the user's consent (before issuing the tokens to the client application and before exposing the users information to a client application) is an important topic. Authorization server often have features which make it possible to remember which authorization the user has already consented to and may skip the user consent verification in some cases.

Some excerpts of the Oauth 2.1 draft:

The Authorization Server might make policy decisions about things such as whether to prompt the user for consent on every authorization or only the first based on the confidence that the Authorization Server is actually communicating with the legitimate client.

[...]

Authorization servers SHOULD consider the level of confidence in a client's identity when deciding whether they allow a client access to more sensitive resources and operations such as the Client Credentials grant type and how often to prompt the user for consent.

[...]

As stated above, the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured.

There is currently no wording about the consent verification (and especially under which conditions the authorization may skip the verification of the user's consent) outside of a generic things in V3:

3.2.5 [ADDED] Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF-style attack where a new application session for the user is created via SSO without user interaction.

Threat: if consent verification can be skipped some may (usually on the ground that the user consent has already been given in a previous grant), this could be exploited by an attacker in order to have the authorization server issue access tokens without the user's consent.

Should some verification/wording about user consent verification be included somewhere in the OAuth chapter?

[randomstuff]

Example of Keycloak not checking user consent for UMA grants: https://github.com/keycloak/keycloak/issues/30779#issuecomment-2192706558 :wink:

[elarlang]

With 3.2.5 I addressed (https://github.com/OWASP/ASVS/issues/1815) (in my opinion) this problem - that you can not create a session for the user without user interaction / consent.

At the moment I can not see the need to create a new and separate requirement. Or this there specific aspect that is not covered? The text for current 3.2.5 can be improved for sure.

[randomstuff]

With 3.2.5 I addressed (https://github.com/OWASP/ASVS/issues/1815) (in my opinion) this problem - that you can not create a session for the user without user interaction / consent.

The 3.2.5 talks about session and is discussed in the context of session management. This actually applies to OAuth (authorization) flows as well which are not really sessions.

[elarlang]

At the moment 3.2.5 just got in with the first wording that came to mind and to the first place that seems suitable.

If we will create new requirement for authorization or for OAuth, it must be some clear and specific reason to do that. My first option could be cover new needs into current 3.2.5, make it more abstract or wider, and maybe cover it in business logic flows.

We can make 3.2.5 more towards asking consent, as for CSRF we have a separate requirement to cover that.

[jmanico]

A note on terminology: OAuth is not really an authorization framework, even though the documentation says it is. This implies traditional access control, which is not OAuth’s job.

OAuth is about access delegation - granting a third-party application or service limited access to resources without sharing credentials.

This distinction is important. Many have noted that it's confusing to call OAuth an authorization framework, and I agree. It can mislead developers. Calling it an access delegation framework—a distinct subset of authorization—is much clearer, and I believe the ASVS documentation should clarify this.

[TobiasAhnoff]

We can make 3.2.5 more towards asking consent, as for CSRF we have a separate requirement to cover that.

Sounds like a good approach to address consent, if it is clear that this also applies to OAuth scenarios (access delegation)

The 3.2.5 talks about session and is discussed in the context of session management. This actually applies to OAuth (authorization) flows as well which are not really sessions.

As a side note, in #2044 it is suggested to have a requirement like "Verify that user consent by default requested a minimal set of scopes.". I think it should be part of this discussion.