A lot of organisations are still using the Implicit Flow for authorization when their client applications are browser based e.g. ReactJS/NodeJS. The problem with this workflow is that it was designed when browsers had a lot less capabilities.
Implicit Grant flow leverages a redirect with the access token in the url.
If someone gains access to your browser history and your token has not yet expired. They can then gain full access to your resources.
As we can see above, this is in the url on a redirect. So a simple script can find these tokens in your browser history. Step 6 below in the Implicit grant is where the issue occurs and the token is recorded in your history.
Authorization Workflow with PKCE
Proof Key for Code Exchange – The PKCE extension prevents an attack where the authorization code is intercepted and exchanged for an access token by a malicious client, by providing the authorization server with a way to verify the same client instance that exchanges the authorization code is the same one that initiated the flow.
Secondly instead of an HTTP GET, an HTTP POST is used to send the token over the wire. Thus the exchange is not recorded in the browser history at all. The token is sent as a payload in the HTTP data section and not the URL.
Notice below the token is requested via an HTTP POST (ClientID, (v), (a) on step 8.
- The user clicks Login within the native/mobile application.
- Auth0’s SDK creates a cryptographically-random
code_verifierand from this generates a
- Auth0’s SDK redirects the user to the Auth0 Authorization Server (/authorize endpoint) along with the
- Your Auth0 Authorization Server redirects the user to the login and authorization prompt.
- The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the mobile application.
- Your Auth0 Authorization Server stores the
code_challengeand redirects the user back to the application with an authorization
- Auth0’s SDK sends this
code_verifier(created in step 2) to the Auth0 Authorization Server (/oauth/token endpoint).
- Your Auth0 Authorization Server verifies the
- Your Auth0 Authorization Server responds with an ID Token and Access Token (and optionally, a Refresh Token).
- Your application can use the Access Token to call an API to access information about the user.
- The API responds with requested data.
Another consideration is that the token endpoint on your Authorization Server of choice MUST support CORS for the trick to come together; not every major vendor supports it yet.
However, if you can influence you customers and client browsers to use later versions and security is a big item on your list. This might be the best case to put forward an upgrade plan.
- Does your Authorization Server supprot CORS?
- Can your clients use modern browsers that support CORS?
If the answer is yes to both, then there is no need to use Implicit Grant with OAuth 2.0
OKTA ands Auth0 are some of the ID providers that support PKCE in SPA clients.
Note: Microsoft Identity V2.0 does not currently support Auth Code Workflow with SPA. This may change in the future as it is a new product and MS are investing in V2.
One thought on “OAuth 2.0 – Authorization Code with PKCE vs Implicit Grant”