[Announcement] OAuth2.1 and OAuth3 drafts

[ybelenko]

OAuth2.1 and OAuth3 drafts has been announced.

OAuth 2.1:

• RFC6749 - OAuth 2.0 Core
• RFC6750 - Bearer token usage
• RFC7636 - PKCE
• Native App & Browser-Based App BCPs(best current practices)
• Security BCP(best current practice):
  • MUST support PKCE for all client types
  • No password grant
  • No implicit flow
  • Exact string matching for redirect URIs
  • No access tokens in query string
  • Refresh tokens must be sender-constrained or one-time use

OAuth 3:

• In development under a new IETF working group
• Re-thinking OAuth from the ground up
• Not backwards compatible
• Consolidate all various use cases in OAuth into a new framework

---

It seems to me that changes to specification should be applied:

• Deprecate implicit in OAuth Flows Object
• Deprecate password in OAuth Flows Object
• Deprecate in: query for apiKey type of security scheme(this one not sure, maybe apiKey isn't related to access tokens)

Don't know whether I should subscribe @aaronpk to this thread, but at least he can confirm that I retyped text from his What's New With OAuth and OIDC? video presentation correctly.

[MikeRalphson]

Thanks for the heads-up, You're right to assume apiKey securitySchemes are not (directly) related to oAuth access tokens.

[aaronpk]

The reasons for dropping the query parameter method of sending access tokens also apply to any sort of API keys, so while that's not necessarily an OAuth issue, it is still a good idea to disallow API keys in query strings.

And yes, this is a reasonable summary of the points in the video 😄

[MikeRalphson]

it is still a good idea to disallow API keys in query strings

It would leave the OAS unable to describe a large number of current APIs - best practices aside.

[philsturgeon]

Yep, OpenAPI is not here to tell people how to build an API, its just a language for letting them describe any piece of junk they might need to describe. I often take the approach of

1. Document the mess so you can see how bad things are
2. Refactor the worst bits first and...
3. Write style guides and standards to help folks avoid similar mistakes in the future

If you take away stuff people need to do 1, you don't get to 2 or 3.

[ponelat]

Can we consider adding a flag to indicate that PKCE is used for Authorization flows? We're currently doing this out-of-band for some tooll, ie: https://github.com/swagger-api/swagger-ui/pull/7438.

[LasneF]

@handrews we may close this one ,

notice than accordingly to this page https://oauth.net/3/ oauth3 project has been abandonned toward to Oauth2.1 extensions...

[handrews]

@LasneF do we support OAS 2.1 already? If not we can leave this open for that (and maybe I'll adjust the title).

[LasneF]

arfter reading carrefully the specification around Oauth 2.1 vs Oauth2 , 2.1 is mostly precision in the protocole , good practices , and depreciation of unsecured model . but till OAS need to support Oauth2.0 we would not remove them

the only addition is PKCE ,that is an addition on top of Authorization Code Flow , that could be a lead to a dedicated flag in the Oauth2 Flow object PKCEsupport : true/false

it s may be a miss as it has been kind of particially integrated inside swaggerUI ... as the MR mentionnd

[handrews]

@LasneF thanks for taking a deeper look! This is helpful. For the spec, we need to take into account the whole tooling landscape and not just what Swagger has done. If Swagger (or any other vendor or open source project) has defined an extension that is working for this, we should look at it as something to possibly incorporate.

[LasneF]

after reflexion it gives me to point :

swaggerUI did it ... because there is a need for sure , it is important to know if the Identity provider support this Oauth2 flavor or not

the solution is somehow partially implemented (https://github.com/swagger-api/swagger-ui/pull/5361) , as not part of OAS the solution would be to have a isPkceCodeGrant flags for the Oauth2 flows

the it raises the question that it is adding to OAS spec a kind of depeendency with Oauth2 spec , and each time Oauth2 invents yet another flavor it requires a change in the OAS spec

i am wondering if it should not be better to just have a instead of a collection of flags , a map or an array of RFC 🙄

something for instance having Oauth2 and flavour supported [rfc7636 , etc ] because as this article mentionned https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1 , Oauth2.1 is a bit messy ... or in a more positive way very extensible

notice that looking on OIDC , and FAPI it is same kind of issue list of RFC/capability keep growing https://openid.net/specs/fapi-2_0-baseline.html is a base line that gather many RFC ...

listing just RFC support could be an option to not follow the updates of specs ...