About the Future of OAuth 2.0 Multiple Response Types

OAuth 2.1, which the IETF’s OAuth WG is working on, will exclude Implicit Grants.

draft-ietf-oauth-v2-1-00 - The OAuth 2.1 Authorization Framework

> The Implicit grant (“response_type=token”) is omitted from this
specification as per Section 2.1.2 of I-D.ietf-oauth-security-topics

The default value for response_type in OAuth 2.1 is “code”, but extended values are also allowed.

> “response_type”: REQUIRED. The value MUST be “code” for requesting an authorization code as described by Section 4.1.1, or a registered extension value as described by Section 8.4.

> Extension response types MAY contain a space-delimited (%x20) list of values, where the order of values does not matter (e.g., response type “a b” is the same as “b a”). The meaning of such composite response types is defined by their respective specifications.

For this extension, OpenID and FAPI use a combination of response_types.

OpenID Connect Core 1.0 incorporating errata set 1

Financial-grade API - Part 2: Read and Write API Security Profile

The behavior of specifying multiple response_types is defined in the OAuth 2.0 Multiple Response Type Encoding Practices specification.

OAuth 2.0 Multiple Response Type Encoding Practices

In this specification, a combination of “code”, “token” defined in OAuth 2.0 and “id_token” defined in OpenID Connect is defined, but if response_type=token is not supported in OAuth 2.1, There will be only “code id_token”.

What will happen to the “Hybrid Flow” of OpenID Connect and the “code id_token token” flow of FAPI Part 2 in the future?

Hybrid Flow is a single authentication (authorization) flow to obtain Access Token on both the Front End and the Back End. This flow avoids the security risks associated with front-end handling of access tokens obtained on the back-end, and it also allows you to limit the scope of Access Tokens for the front-end.

As a personal idea to implement this in Authorization Code Grant, multiple Authorization Codes (e.g., code_for_public_client/code_for_confidential_client) need to be issued in a single authentication (authorization) flow. But this is complicated…

To assuage these future concerns of developers, the OpenID Foundation may need to prepare a proposal to adjust the specification to fit OAuth 2.1.