Impact of Implicit Grant Removal in OAuth 2.1

[Ryo Ito]

One developer asked me about the synchronization of the OIDC and OAuth 2.1 specifications.
'If Implicit Grant is omit in OAuth 2.1, what will happen to OIDC's Hybrid Flow?'

He is concerned that of the multiple Response Type combinations defined in "OAuth 2.0 Multiple Response Type Encoding Practices", only "code id_token" will be allowed to be used.

The summary is here.
https://ritou.medium.com/about-the-future-of-oauth-2-0-multiple-response-types-7e4dac8ceb37

Will OIDC continue to allow the use of "token id_token" and "code token id_token"?
If not, what changes will be required for RPs using Hybrid Flow?

[Nat Sakimura]

We need implicit flow for something like SIOP because there cannot be a token endpoint.

[Ryo Ito]

Yes, I agree with that.

• ID Token via Front Channel : Required in the case of authentication without a token endpoint or as a detached signature.
• Access Token via Front Channel : This is excluded in OAuth 2.1 but Hybrid Flow uses it now.

I think only the latter Access Token should be excluded, but if so, do we need a new definition of how to get an Access Token in both FE/BE applications at the same time?

[Michael Jones]

OpenID Connect uses OAuth 2.0 - not OAuth 2.1 - so OAuth 2.1 won’t directly affect OpenID Connect. That said, OAuth 2.1 is not supposed to introduce any breaking changes, and so the parts of OAuth 2.1 that correspond to to parts of OAuth 2.0 should remain compatible with OpenID Connect.

[Nat Sakimura]

OAuth 2.1 is putting non-normative text clarifying that removal is asking for access token being returned from the token endpoint. The text has not gotten into OAuth 2.1 draft yet so we should monitor it using this ticket.