What is the OAuth 2.0 Implicit Grant Type?
The Implicit Grant Type is a way for a single-page JavaScript app to get an access token without an intermediate code exchange step. It was originally created for use by JavaScript apps (which don’t have a way to safely store secrets) but is only recommended in specific situations.
Anton
Aaron, does it mean that this grant type should be deprecated and never be used? It seems like you state this in “when to use implicit grant” section. Okta API feature, however, currently sets the Implicit Grant for SPA apps.
Aaron Parecki
At this point most OAuth implementations do not use the Implicit flow. But like I said in the post, there are a couple cases where it still makes sense to use it. One is if the authorization server doesn’t support the necessary CORS headers, since the Authorization Code flow requires that a request is made from arbitrary origins. The other is when used in conjunction with OpenID Connect, since the security considerations for ID tokens are very different from access tokens.
Joshua Chamberlain
This post says, "However, the Okta Authorization Code grant requires the client secret, so we’ve taken a different approach noted below."
What is the different approach?
Julian Smiles
This statement is wrong
The main downside to the Implicit grant type is that the access token is returned in the URL directly, rather than being returned via a trusted back channel like in the Authorization Code flow. The access token itself will be logged in the browser’s history, so most servers issue short-lived access tokens to mitigate the risk of the access token being leaked.
The token is returned as a URI Fragment and not a query parameter so the token will not be visible in the logs
aaronpk
Thanks for the note! While you’re correct that the URI fragment will not be in the server’s logs, it will still be logged by the browser in the browser history, like the quoted section says.
Pratik Joshi
That being said, for SPA there is no other way to use any other grant type than Implicit?
aaronpk
Hi Pratik! There’s a much better solution for SPAs now! Check out my more recent post for an example of how to do the authorization code flow with PKCE in JavaScript: https://developer.okta.com/…
mjbraun
I think there are two small errors here:
In the first code block, redirect_uri is set to “https://example-app.com/cal…” but in the second block it’s set to “https://example-app.com/red…”. In the same two code blocks, the state parameter is first shown as “xcoiv98y3md22vwsuye3kch” but then shown as “xcoVv98y2kd44vuqwye3kcq” even though “The state value will be the same value that the application initially set in the request”. Super minor, though.
khandokar sabbir
Hi Aaron,
You wrote “The one remaining reason to use the Implicit flow is if the authorization server doesn’t or can’t support cross-origin requests (CORS)”. My question is that not only Post but also Get request from another origin also considered as cross origin, So also for implicit flow authorization server will need to support the appropriate CORS headers.
khandokar sabbir
May be it is a redirect request