Is the OAuth 2.0 Implicit Flow Dead?
In this post, we’ll look at what’s changing in the Implicit Flow and why.
Bjorn Harvold
Great article Aaron!
Adam Schueller
Very useful! Our security team is NOT happy with using OIDC in SPAs because of the lack of security using implicit flow.
“Start Using the Implicit Flow with PKCE in JavaScript Today” → looks like a typo, you mean ‘Authorization Code Flow’ right?
Aaron Parecki
Thanks! You’re totally right, not sure how that slipped by me! Will push a fix shortly, thanks!
Mikee
Well explained! How do you protect APIs from replay attack? Is it built in OKTA? Thanks!
Aaron Parecki
Thanks! Do you mean replay attacks in obtaining the access token? Authorization codes can only be used once, which prevents that attack.
Mikee
Thanks for the answer. Actually I am currently doing a research. Our team needs to implement a way to handle replay attacks
Aaron Parecki
There are a couple of different replay attacks, so I’m not quite sure which you are referring to. It would be worth reading this document which describes many of those attacks as well as others. https://tools.ietf.org/html…
Chris Becke
https:/{yourOktaDomain}/oauth2/defalut/v1/auth is clearly a typo, and I think you need the authorize, not the auth, endpoint for this kind of thing: https://{yourOktaDomain}/oauth2/default/v1/authorize is whatI need or I get “http method is not supported by endpoint” errors.
Aaron Parecki
Thanks, you’re right, I’m updating this with a fix. The full URL includes authorize, but in any case you should copy the values from your server’s configuration since depending on the type of Okta account you have, and whether you’re using the default authorization server, you might have a different URL as well.
Chris Becke
The only guidance I know to build URLs is Composing Your Base URL, and while ‘default’ might change to an authServerId I don’t see any option to look urls up in the servers configuration.
NitNeKing
Documentation update. You note that you’ll need to grab the client id. I believe this needs to be set in : var config = {
client_id: “0oak2hglgrKY60Lhw0h7”,
redirect_uri: “http://localhost:8080/”,
authorization_endpoint: “”,
token_endpoint: “”,
requested_scopes: “openid”
};
Note: Set your own client_id 
Aaron Parecki
Yes, I left it blank in the example so that you can fill it in with your own.
NitNeKing
Very helpful article. I had one question after implementing the demo (thank you). In the diagram of PKCE flow referenced here: https://developer.okta.com/… , there is one box titled ‘Client App (vue.js)’. I’m assuming you mean this is the browser (client side code)?
The code from the demo is all client side code, so in my head I had it fitting into the diagram under this ‘Client App (vue.js)’. If that is indeed the case, where is the backend for the SPA in this flow? If the SPA is making backend API calls, would you pass the access token obtained (as seen in your demo) as a bearer token to the backend API? If so what checks/validation should be done.
Again, thank you for putting this together.
Aaron Parecki
Yes exactly. In that diagram, the example is a Vue.js client-side app. This post doesn’t use a framework, and instead uses plain JavaScript.
In both cases, the assumption is that the client-side app will be calling other API backends (not drawn in that diagram).
You would use the access token obtained in the flow as a bearer token sent to the API, preferably in the HTTP Authorization header. The client-side app should not do any validation of the access token itself, as that is entirely the job of the backend API.
NitNeKing
Perfect. Any recommendations on best practices on how/where to store the access token once obtained? Cookie? Browser storage? And regarding token validation on the backend, any articles or examples on how the backend should perform this validation? I see its a JWT token, so I can decode and obtain user data that would driver perms/logic. But I take it there should be some validation done every time. Thanks for the quick response!
Simon
Thanks you! Very helpfull post.
Do you have any recommandations on refresh tokens or silent authentication with this flow?
Aaron Parecki
That’s usually done as part of an OpenID Connect flow as well, some info on that here: https://www.scottbrady91.co…
Aaron Parecki
That page in the docs is not very clear, but it starts with your Issuer URI which you can find in your Okta dashboard.
Jeff Lambros
So, we can use a public client (no secret) with the Authorization Code flow w/PCKE in our SPA applications to address the fact we can’t keep a secret. My concern is using the public client, not requiring a secret, to perform the Refresh flow. Don’t we have the same problem not being able to keep the Refresh Token ‘secret’ also?