SECURELY USING THE OIDC AUTHORIZATION CODE FLOW AND A PUBLIC CLIENT WITH SINGLE PAGE APPLICATIONS

This blog post was originally published as “SECURELY USING THE OIDC AUTHORIZATION CODE FLOW AND A PUBLIC CLIENT WITH SINGLE PAGE APPLICATIONS” on the Ping Identity blog.

A shell in the rock’s / Vee

The traditional approach to using OAuth2 or OpenID Connect (OIDC) with Single Page Applications (SPAs) is the OAuth2 Implicit Grant or OIDC Implicit Flow, and many developers still use this approach. More recently, however, the use of the OAuth2 Authorization Code Grant (or OIDC Authorization Code Flow) with a Public Client has been on the rise. Identity Provider (IdP) vendors and bloggers have expressed varying opinions over using the OIDC Authorization Code Flow with a Public Client for SPAs, but this approach — with the proper safeguards — is viable and brings several benefits to the table, including:

I’ve explored these benefits in much greater detail in my previous blog posts. Going forward, the industry is moving toward using the OAuth2 Authorization Code Grant (or OIDC Authorization Code Flow) with a Public Client. In this blog post, we will explore how to best ensure this approach is used with SPAs in a secure manner.

OIDC Authorization Code Flow (with a Public Client) Architecture
To make sure we are all talking about the same thing, let’s assume an architecture and interaction that looks similar to the following diagram.

Furthermore, let’s spell out these assumptions (some, but probably not all, will be true for your use case):

Note: This blog post is not looking at the interaction between the SPA and the API Gateway. If you are interested in that topic, check out previous posts “How To Submit Your Security Tokens to an API Provider Pt. 1” and “How To Submit Your Security Tokens to an API Provider Pt. 2”.

Security Implications
Now, I am coming at this from a specification-centric vision of the world. This means I am really asking the question, “How do we solve X within the confines of the relevant specs A, B, C, etc.?” Most IdPs provide mechanisms for having control over the length of authenticated sessions, obtaining new tokens without the user being prompted to re-authenticate through a security session tracked with a cookie, and additional functionality that is useful, but proprietary.

So what are the security implications here? The OAuth2, OIDC, and JWT (and supporting) specs provide several mitigating controls to help ensure the integrity of an OIDC login flow, including:

Things to Keep in Mind
Now that we’ve looked at some of the security implications of using the OIDC Authorization Code Flow (with a Public Client) for a SPA, here are some things to keep in mind to ensure a better protected system:

Also, keep in mind that all of this assumes that the browser and underlying OS/device have not been compromised in any way. If these are compromised, most of what I’ve mentioned here isn’t going to matter very much.

Summary

Historically, the industry has used the OAuth2 Implicit Grant (or OIDC Implicit Flow) with SPAs. There are no security requirements calling for its continued use. The OAuth2 Authorization Code Grant (or OIDC Authorization Code Flow) should be used with SPAs going forward.

To learn more and for further discussion on these types of topics, check out my blog on API Management, Integration, and Identity on medium.com or read OAuth 2 for SPAs: Recommended Practices from Ping Identity.

Image: A shell in the rock’s / Vee

My focus within Information Technology is API Management, Integration, and Identity–especially where these three intersect.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store