-
-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V51 OAuth: discuss verification of the user consent #2120
Comments
Example of Keycloak not checking user consent for UMA grants: keycloak/keycloak#30779 (comment) 😉 |
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. |
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.
|
Sounds like a good approach to address consent, if it is clear that this also applies to OAuth scenarios (access delegation)
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? |
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:
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:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11#section-7.3.1:
|
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 |
Perhaps this works?
|
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
|
This is additional 4 requirements? |
Yes this is all quite complexe/cumbersome. Could be simplify/merge all these requirements into something like:
This skips the "bypass consent completely for some trusted clients". |
Or maybe:
|
Discussion:
|
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:
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:
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?
The text was updated successfully, but these errors were encountered: