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.
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.
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
Same for Deutsche Telekom. Our javascript clients also use code flow with CORS processing and of course redirect_uri validation.
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.)
