V51 OAuth: Consider narrowing or expanding the scope for the OAuth2 chapter

[TobiasAhnoff]

A suggestion is to define the scope for the V51 OAuth chapter more clearly. Either to make it more general and include OIDC or be more specific, excluding OIDC and all OAuth2 flows except the Code flow.

If the scope for ASVS should only be OAuth2 Code (the other OAuth2 flows from 6749 are not mentioned in the verifications), then it would be good to make that clear as well. Perhaps then change the title to "OAuth 2.0 Code flow" and remove the OIDC details from verifications? Or is the intention to include OIDC (or just OIDC Code flow)? Then it would be good if the title and first sections reflected that, and also have reference links to OIDC specs. The downside of including OIDC is of course a bigger scope to maintain...

To me, the current title and first sections in the chapter implies that verifications will only address OAuth 2.0, perhaps all flows in RFC 6749? OIDC is mentioned, referred to as a "a simple identity layer on top of the OAuth 2.0 protocol", which implies OIDC is probably going to be out of scope? But then, verification 51.1.2 and 51.2.2 refers to OIDC (nonce and id-token,) which is a little surprising given the title, the text in the first sections, and that there are no references to OIDC specs.

Another scope feedback: Given that the "resource" and "authorization_details" parameters are mentioned, this implies that the RFCs https://www.rfc-editor.org/rfc/rfc8707 and https://www.rfc-editor.org/rfc/rfc9396 are included in the scope? Is the intention to include more additional specs from https://oauth.net/specs/ in the scope? Like PAR etc.

It is not easy to decide on a good balance, level of detail, and so on. Either way, it would be good with a more clearly defined scope and discussion about it. Then, I my opinion, it will be easier to add feedback on specific verifications that can be added or removed, to reflect the flows in scope.

[elarlang]

From pentesting experience, everyone using OAuth/OIDC and only a few know, what those are, why and for what purpose they exist, and how they should be used.

To find the balance between details and abstractation is hard job. The situation at the moment is, that the entire chapter - including chapter texts and requirements - is open to feedback and recommendation.

Personally, I would like to see OAuth and OIDC covered and clearly separated to point out, that Authorization and authentication tools work hand-in-hand, but those are not the same tools and one should not mix them. A widespread problem is that OAuth is used for authentication, as I pointed out in another issue #1916 "Discussion/Proposal 4".

For the summary - if you have a vision, of how it should be organized, please share it! :)

ping @tghosth @jmanico @csfreak92

[jmanico]

Personally, I would like to see OAuth and OIDC covered and clearly separated...

Agreed, Elar.

[tghosth]

I agree that it would be good to cover both OAuth2 and OIDC.

There will be a tricky balance between too much detail and too little detail. I think we can refer to supporting documentation if necessary. For example in 5.0 the logging chapter is likely to refer to the OWASP logging cheatsheet and the password storage section is likely to refer to the password storage cheatsheet.

@TobiasAhnoff @csfreak92 what are your thoughts?

[csfreak92]

I agree it would be good to cover both OAuth2 (and potentially working on OAuth2.1) and OIDC, but we need to find the right balance between too much detail and too little detail, which is something we try to deal with. :)

Maybe we can loop in @jsherm-fwdsec as he had initial ideas for OIDC in one of our issues particularly #1826. Any thoughts Jordan?

[elarlang]

The ping-pong here in the issues is at a really slow pace. It is possible also to organize some video calls and have quick discussions and overviews, of what is done, what should be done, what the expectations and abstract goals, etc.

[TobiasAhnoff]

Sorry for the late reply, I started working on it, but other things got in the way....I would be happy to attend a video call meeting and I plan to reply here during this week...

[jsherm-fwdsec]

Thanks @csfreak92. I'd agree that OAuth/OIDC need to be split out in to their own respective sections. @elarlang happy to attend a video call as well if that would help figure out the scope and perhaps we can divide and conquer.

[TobiasAhnoff]

I will try to express some sort of vision, it is a challenging topic!

What do we want to achieve by adding one OAuth2 and one OIDC chapter to ASVS?
(As suggested, I also think it is good to keep them separated, and reference each other when needed)

The way I see it ASVS could have three goals:

1. Make readers of ASVS aware of OIDC security profiles (FAPI) and OAuth2 BCPs etc
2. Highligth the essence of the specs as actionable verifications in ASVS
3. Highlight common implementation mistakes that might not be obious when reading the specs, but often cause vulnerabilities or introduce risk

The first one is easy! Once it has been decided on clear vision and scope!
I believe the first sections of text in the OAuth2 chapter should make it clear to the reader that even if ASVS lists a set of important verfications, any system using OAuth2 should (at least) be aware of guidance from https://oauth.net/2.1/ (in particular https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps, which is a great document to read to understand OAuth and general web security concerns).

For the OIDC chapter FAPI (https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html) should be referenced in a similar way, with the note that it is good to read and understand for everybody using OIDC, but following every guidance is for L3 applications.

Then ASVS must decide on which flows to include in the scope and make that clear from the start of the OAuth2 and OIDC chapters. Should ASVS only focus on classic browser based apps or should mobile clients be include? Should "detached" flows (device grant and CIBA for OIDC) be included? If decided on keeping focus on browser based apps, this means just the Code flow (ROPC and Implicit are "omitted", see https://oauth.net/2.1/), should OIDC id-token flow be included? That flow is commonly used for login and federation scenarios.

The client-credentials flow should perhaps be included in other ASVS chapters for "service integrations" and authorization or should it be part of this chapter?

A suggestion is to start with focus on just the Code flow for browser based apps and then, when having a "release candidate draft" consider expanding the scope to perhaps include native mobile apps (https://oauth.net/2/native-apps/). Perhaps the OIDC id-token flow should be included from the start, since it is commonly used and address the login scenario where you don´t want access tokens (and involve OAuth).

It might also be good to provide more details in cheatsheets, but personally, I would probably go for the OAuth2/OIDC specs if I needed more details than ASVS could provide. But it is hard to say before there is an "release candidate draft".

The second goal is the hard one. For OIDC, FAPI kind of captures what ASVS could look like, so it might be hard to avoid being some sort of copy of that...but we don´t know until we tried!

For OAuth2, I don´t think there is such short and percise guidance as FAPI, so in a way ASVS could fill that gap, But it is challenging with the level of detaial and how many specs that should be in scope, should e g RAR be included? I would argue that PKCE and PAR should be included since they play an important role and are included in FAPI 2.0. I would hesitate to include details from RAR and Resource indicators RFCs, this is of course good security features, but they are in my experince not commonly used and, requires some context to provide value, and there are a lot of specs...so the scope for ASVS might "explode" if not narrowing the scope.

The third goal would be easy, if there was some sort of a OWASP TOP 10 for OAuth2/OIDC...
A suggestion is to try this anyway, it might provide value to the readers of ASVS that are not found in the specs.

For example, one of the first things we check (in a white-box penetration test for applications using OAuth2/OIDC) is what kind of token service they are using? Is there any custom code involved? If so, are the developers who built the service or "extensions" aware of BCPs etc, are they using the recommended flows? One mistake to make when implementing OAuth2/OIDC solutions is to build things on your own...In my opinion, I think it would be good if ASVS provides guidance on topics like this, based on experiences, it is not obvious when reading the specs that building your own or not protecting the signing-key (e g by sharing it with resource servers) introduce risk.
(Perhaps verifications like this will not be part of the OAuth2 or OIDC chapter since they concern general application security found in other chapters, so maybe it could be expressed in text with references to those verifications from the OAuth2/OIDC chapater, see in example comments in #1925)

Looking forward to continue the discussion!

[elarlang]

I try to give answers to the questions presented in the comment.

What do we want to achieve by adding one OAuth2 and one OIDC chapter to ASVS?

At the moment we can say, that it is not "hardcoded" or clearly defined, the goal is to find it out.

If we take a look at OWASP Top 10 2021, A01 is Broken Access Control, and A05 is security misconfiguration. I have not investigated the stats behind that, but I assume that misconfigured and incorrect usage of OAuth is an important "donor" for those positions.

Then ASVS must decide on which flows to include in the scope and make that clear from the start of the OAuth2 and OIDC chapters. Should ASVS only focus on classic browser based apps or should mobile clients be include? Should "detached" flows (device grant and CIBA for OIDC) be included?

Although nowadays browser-based flows are widespread for the 1st party usage, OAuth was not built for this kind of usage. I'm not convinced that is the correct way to use or to allow to use OAuth. Often it is unnecessary overengineering and creating many vulnerabilities due to misconfigurations.

For ASVS, we are not limited only to browser-to-server communication, service-to-service must be covered as well - the actual goal for the OAuth.

.. should OIDC id-token flow be included?

and

Perhaps the OIDC id-token flow should be included from the start, since it is commonly used and address the login scenario where you don´t want access tokens (and involve OAuth).

Yes, often OAuth is used for authentication and OIDC should be used instead.

The client-credentials flow should perhaps be included in other ASVS chapters for "service integrations" and authorization or should it be part of this chapter?

I think OAuth specific requirements should all be in one place.

The second goal is the hard one. For OIDC, FAPI kind of captures what ASVS could look like, so it might be hard to avoid being some sort of copy of that...but we don´t know until we tried!

By principle, it is not a problem to "copy" the content - there are arguments and research behind that. Even if you do your own, you should probably reach the same result and the end result should be really similar. In the same way, many requirements in the authentication and session management come from NIST.

Another question - should we duplicate that, or should we have abstract requirement "Verify that OIDC setup and configuration is ...".

For OAuth2, I don´t think there is such short and percise guidance as FAPI, so in a way ASVS could fill that gap, But it is challenging with the level of detaial and how many specs that should be in scope, should e g RAR be included?

My idea is to address frequently happening and common mistakes with separate requirements. We are not able to cover all the OAuth extra-extra-n-extra level security mechanisms. In reality, there are so many separate add-on specifications in development, that in a year of ASVS release (whenever it will happen), it will be outdated already.

One mistake to make when implementing OAuth2/OIDC solutions is to build things on your own...In my opinion, I think it would be good if ASVS provides guidance on topics like this, based on experiences, it is not obvious when reading the specs that building your own or not protecting the signing-key (e g by sharing it with resource servers) introduce risk.

ASVS may address widespread problems with separate requirement, but the goal and the scope for the ASVS is not to provide guidance.

[elarlang]

ping @csfreak92 @TobiasAhnoff @jsherm-fwdsec

We should find a common communication channel to discuss suitable times for video calls or just chat on the topic. I think the best option is to use the OWASP Slack for that. Please find your way there (if you are not there yet) and I'll open a separate channel for that.

[jsherm-fwdsec]

ping @csfreak92 @TobiasAhnoff @jsherm-fwdsec

We should find a common communication channel to discuss suitable times for video calls or just chat on the topic. I think the best option is to use the OWASP Slack for that. Please find your way there (if you are not there yet) and I'll open a separate channel for that.

I started a thread on OWASP Slack :)

[TobiasAhnoff]

ping @csfreak92 @TobiasAhnoff @jsherm-fwdsec
We should find a common communication channel to discuss suitable times for video calls or just chat on the topic. I think the best option is to use the OWASP Slack for that. Please find your way there (if you are not there yet) and I'll open a separate channel for that.

I started a thread on OWASP Slack :)

I have joined the OWASP Slack, but I cant find the thread :)
ping @jsherm-fwdsec