OAuth2 implicit grant is not secure

[AxelNennker]

This is a PR for all versions of OAI.

The IETF OAuth2 working group considers the OAuth2 implicit grant NOT to be secure.
Time has changed. Implicit grant was secure enough, but in 2024 it isn't .
Please see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics.html

Technology has changed. For example, the way browsers treat fragments when redirecting requests has changed, and with it, the implicit grant's underlying security model.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics.html#section-2.1.2

In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated.Clients SHOULD instead use the response type "code" (aka authorization code grant type)

This PR adds a security note whenever OAI markdown mentions implicit grant in definitions and examples

BTW: I wished that OAI would rely more on OpenId Connect because OIDC is the authentication framework on top of OAuth2. Whenever an API use requires user consent OIDC authorization code flow should be used.

[shilpa-padgaonkar]

This PR is also in line with OWASP security guidelines https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05-Testing_for_OAuth_Weaknesses

[darrelmiller]

Hi @AxelNennker Thank you for the submission. However, we do not make changes to published versions of the specification. We could consider adding this to our 3.0.4 and 3.1.1 patch releases.
However, I'm not really sure we want to get into the business of providing security guidance. API Keys are not secure either, neither is basic authentication. OAuth client credentials are not secure from a desktop or mobile application.
Developers should not be relying on the OpenAPI specification to tell them how to build a secure API.

[AxelNennker]

Well, OAS is very influential and an important source for developers and not everybody is reading security consideration of IETF or OIDF standards, or OAuth 2.0 Security Best Current Practice that recommends authorization code flow over implicit grant type.

OIDC is 10 years old and OAuth2 older. Technology has changed, and that something is standardized does not mean that it is a good idea to use it, because now there are better security standards like e.g. PKCE to protect against Cross Site Request Forgery.

OAS is like stackoverflow - very influential. And developers often copy example code from stackoverflow and OAS because developers want to get things done. Developers then often miss that the stackoverflow example does not take security into account because the point of the example is showing how something can be programmed. Security is too often left as an exercise to the reader.

I think OAS has an even bigger opportunity to help developers than Stackoverflow because in Stackoverflow everybody can add their bad example but in OAS the documentation is vetted by API experts.

I am grateful that OAS added openid connect support and oauth2 support. How to secure an API is very important, and OpenId and OAuth2 are the most commonly deployed authentication and authorization schemes.

Please add guidance for developers how to choose grant types and not to use implicit mode in 2024.

[handrews]

Developers should not be relying on the OpenAPI specification to tell them how to build a secure API.

Maybe add a note to the security considerations document that the appearance of a technology in the specification does not mean that its use is in accordance with best practices, or something like that? (hmm... I should have looked at this before approving the other PR 🙃 )

[handrews]

@AxelNennker what you want might be more suitable for the security section of the learn site as there are endless topics that the specification could address, but making it too large makes it harder to digest.

[danielfett]

Speaking as a co-editor of the OAuth Security Best Current Practice RFC draft: Examples are important and it would be great if the OAS examples were secure by default. That said, I have no clue what the process here is or if the proposed change is appropriate.

BTW: I wished that OAI would rely more on OpenId Connect because OIDC is the authentication framework on top of OAuth2. Whenever an API use requires user consent OIDC authorization code flow should be used.

User consent without OpenID Connect is perfectly fine.

[miqui]

Developers should not be relying on the OpenAPI specification to tell them how to build a secure API.

Maybe add a note to the security considerations document that the appearance of a technology in the specification does not mean that its use is in accordance with best practices, or something like that? (hmm... I should have looked at this before approving the other PR 🙃 )

Exactly, well said @handrews. Overall I agree with @darrelmiller , but the spec SHOULD include some normative language, etc..etc. This is one reason I made the MoonWalk proposal of deprecating (optional) security schemes that are not a good idea.

[LasneF]

@miqui the deprecation could even occurs in OAS 3.2 or meaning deprecation not beeing a breaking change, it provides an indication for the future non support (even if i am not sure it is the right direction as OAS is not here to dictate a way but to describe a way of doing)

but may be deprecation is even not a good idea , but rather a good narative

[handrews]

After discussion in today's TDC call, I've filed issue #3603 to follow up on this in the versions and documents that we can change now. Closing this in favor of that issue.