How can an AS support both 2.0 and 2.1 clients concurrently

[aaronpk]

We may need some additional client registration metadata parameters in order to enforce some of the non-optional things in 2.1 while allowing 2.0 clients to still treat them as optional.

Related to #97

[aaronpk]

We need AS metadata to tell clients what kind of clients it supports: OAuth 2.1 clients, or both clients. If the parameter doesn't exist, clients can assume the server only supports 2.0.

AS metadata:

• oauth_versions: ["2.1","2.0"]

Should go in a new metadata section before extensibility https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#section-6

The client metadata needs to indicate whether the AS should follow 2.1 processing rules or 2.0 processing rules.

Client metadata

• oauth_version: "2.1"

Need a new client metadata section in https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#section-2.3.1

[aaronpk]

• There are multiple ways someone might want to migrate clients
• How do I support both 2.0 and 2.1 clients at the same time
• How do I not break existing clients, some of which might never upgrade
• Provide clients a way to opt in to 2.1 behavior in a slow rollout (e.g. native apps where upgrades roll out slowly)

[dickhardt]

posted the following to mail list for discussion

There are a number of protocol features that are valid in OAuth 2.0 that are not valid in OAuth 2.1. For example, the code_challenge is REQUIRED in OAuth 2.1

We are proposing the following normative additions to support version support discovery between the AS and the client.

For a client to know if an AS supports 2.1, the AS metadata contains a new "oauth_versions_supported" property that is an array of version strings.

example:

"oauth_versions_supported": ["2.0","2.1"]

This indicates the AS supports both OAuth 2.0 and OAuth 2.1

For an AS to learn that a client supports 2.1, the client would include in its metadata the "oauth_version" property which would contain the string "2.1"

example:

"oauth_version": "2.1"

Note that there is no explicit signal from the client or server at runtime if a given request or response is conforming with OAuth 2.0 vs OAuth 2.1

[gffletch]

Is it possible to add more clarity on how a client provides the "metadata oauth_version" value? Is this a new parameter in Dynamic Client Registration? Is it something that the AS should make available in it's developer portal to allow the client to specify to the AS which version of OAuth it's supporting?

What about clients that work with multiple Authorization Servers not all of which may be supporting 2.1?

[njwatson32]

The AS exposing versioned endpoints makes the most sense to me as a way for clients to opt into 2.1 or not. It allows clients to implement fractional rollouts to gradually switch over to 2.1, as opposed to a flag on the client itself which is a binary switch.

Versioning endpoints would also greatly benefit from versioned AS metadata, e.g. https://issuer.example.com/.well-known/oauth-authorization-server/2.1. (That could still be coupled with oauth_versions_supported for all published AS metadata.) Without that, it would be infeasible for large AS to update authorization_endpoint without breaking some clients.