OAuth 2.0 for Mobile Apps and SPAs

In one of my earlier articles on OAuth 2.0, we looked at how the OAuth framework can provide delegated access to the client application by issuing an authorization grant. Authorization grant refers to the way the client application gets the access token. There are various types of authorization grants that can be used depending on the use case and security considerations.

We also looked at how the Authorization Code grant type works by exchanging the authorization code for an access token over the back channel. The authorization code grant utilizes both the front channel and back channel for a user to grant delegated access to a backend server application (client application). In this flow, the access token is never sent to the browser and is securely handled over the backend channel between the client application and authorization/resource servers. The client application can securely handle client credentials (client id and client secret) by storing them in a secured storage space or security vault.

OAuth 2 – Implicit Flow

Implicit flow is another grant type defined in OAuth 2.0 specification for frontend web client applications. The implicit flow is similar to Authorization Code flow, however with one major difference being that there is no authorization code shared with the client application. The client application directly receives access token from the authorization server over the front channel since the request is directly made from the browser. This is due to the limitation with frontend web and mobile applications not able to securely store a client secret due to which there is no client authentication in the implicit flow.

Due to the limitations described above and the security concerns, the implicit flow cannot be safely used for frontend web and mobile application. Recently, the OAuth specification released an enhanced version of authorization code grant to mitigate security concerns of sharing access token over front channel. This enhanced version of authorization grant type is known as Authorization Code Grant with PKCE.

OAuth 2 – PKCE

PKCE (Proof Key for Code Exchange) is an extension to the authorization code flow to prevent certain attacks and allow public clients to securely perform OAuth flow. It is recommended that SPAs (Single Page Applications) and other browser based frontend applications shouldn’t use implicit flow and instead implement Authorization Code flow with PKCE.

With PKCE extension, the authorization code flow doesn’t depend on client credentials to exchange authorization code for access token. Instead a one-time code challenge is used which doesn’t require the client application to store any client secret.

The diagram above highlights how PKCE enhances authorization code flow with the introduction of one-time code challenge.

  • Step 1: The client generates a random string known as code verifier. It also generates SHA256 hash of code verifier string. This hash value is known as code challenge.
  • Step 2: The client sends the request to authorization server with the authorization code grant type. This request also includes the code challenge generated by the client application.
  • Step 3: Authorization server authenticates the user and request for the consent to authorize access to protected resources.
  • Step 4: The client application receives the authorization code from authorization server.
  • Step 5: The client applications sends the request to authorization sever to exchange authorization code for access token. The request contains code verifier that was generated by the client application.
  • Step 6: The authorization server validates code verifier by comparing it’s hash value with the code challenge it received in Step 1.
  • Step 7: If authorization server is able to successfully validate code verifier, the access token is sent back to the client application to access protected resources.

So, essentially PKCE is like a one-time password replacement for static client credentials. Since the validation of code verifier and code challenge are based on SHA256 hashing algorithm, it can be considered secure since the code challenge cannot be used to derive the code verifier.

Authorization code flow with PKCE is the recommended OAuth 2 grant type for any new web application application including SPAs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s