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: keycloak/keycloak#30779 (comment) 😉

[elarlang]

With 3.2.5 I addressed (#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 (#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.

[elarlang]

The goal here probably should be a quite abstract requirement. To achieve that, I think we should list situations it must cover.

@randomstuff - I think you can provide some examples for a starter?

[randomstuff]

A note on terminology: OAuth is not really an authorization framework

Well it is (still) (in a sense) an authorization framework in the sense that it is about resource owner authorizing access to the resource but not an authorization framework in the sense that its not so much about enforcing business rules about the deciding if this user actually has access to the resource. (?)

[randomstuff]

Wording a requirement on this is not easy because on the one hand consent verification is important but on the other hand some uses cases will require to skip user consent in some cases (for example some Token Exchange use cases).

Straw man proposal:

Verify that, the authorization server does not process interactive authorization requests automatically without user consent if the identity of the client cannot be assured. (← this one comes straight from the OAuth 2.1 draft)

Verify that the authorization server does not process interactive authorization requests automatically unless skipping consent verification has been explicitly configured for this trusted client or the user has consented to this authorization recently. If the authorization server remembers user consents, these remembered consents must have an expiration after which a new user consent verification is required again. ( ← this is hairy)

Verify that, if the the authorization server remembers consents, it provides a mean for the user to revoke them. (?)

Nor covered (for now?): things like Token Exchange which might be exploited for "consent escalation".

[elarlang]

Is the "interactive" here understandable?

Quotes from "The OAuth 2.1 Authorization Framework"

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11#section-7.3:

The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11#section-7.3.1:

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. This includes the case where the user has previously approved an authorization request for a given client ID -- unless the identity of the client can be proven, the request SHOULD be processed as if no previous request had been approved.

[randomstuff]

Is the "interactive" here understandable?

Maybe "user-to-machine"? The meaning is not exactly the same but I supposed that would do?

[randomstuff]

Coming from #2036, I'm adding to the scope of this issue the question of including sufficient information about the content of the authorization_details (RAR) in the consent validation.

[TobiasAhnoff]

Perhaps this works?

Verify that, if the identity of the client cannot be assured, the authorization server requires user consent for all user interactive authorization requests.

Verify that processing interactive authorization requests automatically (without user consent) is only allowed if skipping consent verification has been explicitly configured for a trusted (identified) client or if the user has consented to this authorization recently. If the authorization server remembers user consents, these remembered consents must have an expiration.

Verify that, if the the authorization server remembers consents, it provides a mean for the user to revoke them.

[TobiasAhnoff]

Given that RAR is included as suggested in #2151 then it is also good to add "sufficient information about the content of the authorization_details (RAR) in the consent validation", perhaps

Verify that the user consent contains sufficient information about the content of the RAR authorization_details parameter.

[elarlang]

This is additional 4 requirements?

[randomstuff]

Yes this is all quite complexe/cumbersome.

Could be simplify/merge all these requirements into something like:

Verify that the authorization server does not process user authorization requests without the user consent. If user consent is verified interactively, the consent prompt must contain sufficient and clear information about the content of the requested authorizations. This include the identity of the client application, the nature of the requested authorizations (scope, resource servers, RAR authorization details) and the lifetime of these authorizations.

Verify that, if the authorization server remembers user consent across different authorization requests, it is only done if the identity of the client can be assured and that remembered consents have a expiration.

This skips the "bypass consent completely for some trusted clients".

[randomstuff]

Or maybe:

Verify that the authorization server mitigates client impersonation by always explicitly asking for user consent in user authorization requests if the identity of the client cannot be assured.

[elarlang]

Discussion:

• consent management can be wider topic than OAuth / OIDC, maybe something to V8.3
• todo: recheck V8 and asking permissions from a end-user