OWASP
V51 OAuth: discuss verification of the user consent
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?
Example of Keycloak not checking user consent for UMA grants: https://github.com/keycloak/keycloak/issues/30779#issuecomment-2192706558 :wink:
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.
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.
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.
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.
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.
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?
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. (?)
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".
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.
Is the "interactive" here understandable?
Maybe "user-to-machine"? The meaning is not exactly the same but I supposed that would do?
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.
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.
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.
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".
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.
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
Here follows an attempt to move part of the requirement outside of the OAuth chapter.
General requirement which could be outside of the OAuth chapter:
Verify the any consent prompt to the user contains sufficient and clear information about what is being consented to and that the user can revoke his persistent user consents.
Requirement for the OAuth chapter:
Verify that the authorization server mitigates malicious authorization requests by malicious clients by ensuring that the user consents to each authorization request. This consent must 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 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.
In V8.3 we have requirement V8.3.3:
V8.3.3 Verify that the application provides guidance regarding how it collects and uses of personal data and that users have to provide opt-in consent for this use.
But with this wording it covers only informing the user, but does not cover "consent management".
Change in the first part:
Verify that the authorization server ensures that the user consents to each authorization request to mitigate malicious authorization requests by malicious clients. This consent must include the identity of the client application, the nature of the requested authorizations (scope, resource servers, rich authorization request (RAR) authorization details) and the lifetime of these authorizations.
To be sure - is the second proposed requirement is alternative to the first one or additionally to the first one?
I think the second is in addition to the first one, where the first one is suggested "outside of the OAuth chapter". A suggestion is to also include "requested a minimal set of scopes", and add this to the first one. Then, if I have understood discussion in this topic, we would have three requirements (where the first one is not for the OAuth chapter)
Verify that any consent prompt to the user contains sufficient and clear information about what is being consented to, requests a minimal set of privileges, and that the user can revoke his persistent user consents.
Verify that the authorization server ensures that the user consents to each authorization request to mitigate malicious authorization requests by malicious clients. This consent must include the identity of the client application, the nature of the requested authorizations (scope, resource servers, rich authorization request (RAR) authorization details) and the lifetime of these authorizations.
Verify that, if the identity of the client cannot be assured, the authorization server mitigates client impersonation by always explicitly asking for user consent in user authorization requests.
Verify that any consent prompt to the user contains sufficient and clear information about what is being consented to, requests a minimal set of privileges, and that the user can revoke his persistent user consents.
Just a brief note on this. Some services (like my bank) forces a set of permissions on the client. Some services (like Google) gives the user the option to choose from a larger list of scopes.
I'm not sure how to add this in but I think it's important.
- Jim
Perhaps this?
Verify that any consent prompt to the user contains sufficient and clear information about what is being consented to, by default requests a minimal set of scopes needed by the client, and that the user can revoke his persistent user consents.
Based on discussions concerning the first part of 3.2.5, the suggestion is to have all three suggested "consent requirements" in the OAuth chapter (and update 3.2.5)
I think the second is in addition to the first one, where the first one is suggested "outside of the OAuth chapter".
Yes, my intent was to have the first one outside of OAuth section.
Verify that any consent prompt to the user contains sufficient and clear information about what is being consented to, by default requests a minimal set of scopes needed by the client, and that the user can revoke his persistent user consents.
I think there is 3 separate requirements:
- user is informed - easy to test, does not require extra access to program code, level 2
- minimal set of scopes - complicated to test, may require access to program code, level 3. Sure, that is not covered by any other requirement?
- user can revoke consent - separete test-case, level 2
How about this? (one for when consent is required, one for what the consent must (or should?) include and one for managing consents)
Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must explicitly prompt the user for consent.
Verify that any consent prompted to the user contains sufficient and clear information about what is being consented to. This must include: The identity of the client application, the nature of the requested authorizations (typically based on scope, resource servers, RAR authorization details), the lifetime of these authorizations, and by default only request required authorizations.
Verify that the user can review, modify and revoke granted consents at any time.
In v4 we change the word "user" to "consumer" so its more generic, my suggestion.
@TobiasAhnoff, OK for me.
I'd want to add "always" here:
Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent.
It's not strictly needed but I feel it might better convey the meaning?
In v4 we change the word "user" to "consumer" so its more generic, my suggestion.
Good point, but I think in this context is is more clear since we have user consent for authorizing a client, in V4 consumer is used to include both users and clients since it applies to both.
So I suggest to keep user and client separate here, ok? @jmanico
Verify that any consent prompted to the user contains sufficient and clear information about what is being consented to. This must include: The identity of the client application, the nature of the requested authorizations (typically based on scope, resource servers, RAR authorization details), the lifetime of these authorizations, and by default only request required authorizations.
Is this "must include" part written somewhere in specification? If we can be abstract enough with this one, we can include it into the other one
Verify that the authorization server ensures that the user consents to each authorization request and provides information about what is being consented to. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent.