-
-
Notifications
You must be signed in to change notification settings - Fork 665
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
discussion OAuth/OIDC: accepted flows and grants #1970
Comments
There are other grants that we need to allow for, such as the Client Credentials grant used by clients to access resources about themselves rather than to access a user's resources, or in other words machine-to-machine authorization. This is documented in the OAuth 2.1 spec here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10#section-1.3. PKCE is an extension of the Authorization Code grant and this grant can't be used in all cases. I know that positive requirements are preferred, but in this case if we want to keep it simple, it would probably make more sense to document which flows are legacy due to their insecure nature rather than state all of the accepted flows. I agree that Authorization Code Flow with PKCE is preferred when used in the right context though. The way I see it there are two options:
|
If searching solutions from grant/flow allow-list or black-list, my brain goes to endless loop. For brainstorming - maybe we should not talk about flows and grants at all, but the reasons and attack vectors, and why those got deprecated. For example, "you need to have a defense against authorization code injection", but how do you do it without PKCE? At the same time, an authorization code injection attack is available, if an attacker can access the token endpoint. If BFF is used, the likelihood is so small, that personally, I would not put the requirement there (based on my current knowledge). |
Yes, it would. Especially since new flows could be added later on. For example, we wouldn't want to disallow CIBA. |
In case @damienbod doesn't find the way here, I copy the argumentation provided in #1969 (comment):
|
This is a very controversial statement. Some counterpoints:
|
Hi @jmanico, thanks for your feedback. The third point is the only use case I was thinking about. (no access token used in the flow) Example of usage: id_token exchange for external MFA between 2 IdPs |
Why would you not want to use the authorization code with PKCE in this case? |
I think discussion is solved via #2043 / #2096 with modified requirement:
Any not covered aspects from this issue? |
Current requirements are in https://github.com/OWASP/ASVS/blob/master/5.0/en/0x51-V51-OAuth2.md#v511-authorization-server
From different discussion and comments, there have been recommendation which flows should be disallowed (e. g. password grant, implicit flow)
In #996 (comment) I proposed to take step to the future and adapt OAuth 2.1, which means allowing only PKCE to be used.
From @deleterepo in #1969 "proposal 1"
This applies to both OAuth and OIDC. As per https://oauth.net/2/grant-types and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-implicit-grant. If preferred we can consolidate this with 51.1.6 about Resource Owner Password Credentials Grant, but it might make sense to make it a separate requirement to keep it granular, because these grants are vulnerable to different attacks that we are highlighting.
So my proposal is, that we accepting only PKCE.
Questions to solve:
The text was updated successfully, but these errors were encountered: