Replacing OAuth2 Implicit Grant with Authorization Code without Client Secret

Question

OAuth 2.0 Auth Code without Client Secret is being used in lieu of Implicit Grant for client-side JavaScript apps by a few companies. What are the general advantages / tradeoffs of using Auth Code without Client Secret vs. Implicit Grant? Are there more companies and/or standards organizations moving this way?

Red Hat, Deutsche Telekom and others have moved this way per this article and the IETF OAuth mailing list posts below.

• https://aaronparecki.com/oauth-2-simplified/

Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.

...

Previously, it was recommended that browser-based apps use the "Implicit" flow, which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written, the industry best practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow, such as using the state parameter. References: Redhat, Deutsche Telekom, Smart Health IT.

Here are the messages referenced above.

Red Hat

For our IDP [1], our javascript library uses the auth code flow, but requires a public client, redirect_uri validation, and also does CORS checks and processing. We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a browser redirect

Deutsche Telekom

Same for Deutsche Telekom. Our javascript clients also use code flow with CORS processing and of course redirect_uri validation.

SMART Health IT

We've taken a similar approach for SMART Health IT [1], using the code flow for public clients to support in-browser apps, and <1h token lifetime. (We also allow these public clients to request a limited-duration refresh token by asking for an "online_access" scope; these refresh tokens stop working when the user's session with the AS ends — useful in systems where that session concept is meaningful.)

Answer 1

There was a big change in paradigm regarding public clients (SPA applications) in late 2018. Previously recommended implicit flow was criticized by a number of parties as quoted in the original question. In December 2018 two IETF drafts were published describing the possible attack vectors and best practices. Both recommend using authorization code flow instead of implicit flow.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-11
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-00

Answer 2

The answer lies in this spec https://www.rfc-editor.org/rfc/rfc8252 It talks exclusively about OAuth 2.0 for Native Apps. Section 8.2 https://www.rfc-editor.org/rfc/rfc8252#section-8.2 explains why Implicit flow is not preferred even for public clients. Microsoft Azure AD also has taken this route.

"The OAuth 2.0 implicit grant authorization flow (defined in Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice of performing the authorization request in the browser and receiving the authorization response via URI-based inter-app communication. However, as the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED.

Access tokens granted via the implicit flow also cannot be refreshed without user interaction, making the authorization code grant flow -- which can issue refresh tokens -- the more practical option for native app authorizations that require refreshing of access tokens."