OpenID Connect for Single Page Applications

OpenID Connect is an identity protocol that was designed not just for traditional Web SSO but it also caters for modern use cases like native mobile applications and API access. Most of these use cases have a clearly defined an preferred pattern as to which “grant type” or “flow” can be applied to it. For a good overview of that you can visit which presents the flow chart below:


When dealing with Single Page Applications (SPAs) things become a bit more blurry since they can be seen as a mix between traditional Web SSO and API access: the application itself is loaded from a – possibly protected – regular website and the Javascript code starts calling APIs in another – or the same – domain(s). The spec, like the previous diagram, points to the so-called “Implicit grant type” for passing token(s) to the SPA since that grant was specifically designed with the “in-browser client” in mind.

Apart from some “Identerati” changing their minds about recommending Implicit over Authorization Code with a public Client for this use case – that’s probably a topic for a different post – implementing the Implicit grant type is not very popular from what I have seen in the field. Its main drawbacks are:

  • Implicit requires validation of the ID Token by the Client which means that crypto is done in the browser; this requires relatively heavy-weight libraries and more importantly, increases complexity
  • because it is not possible to keep a client secret in the browser, Implicit means using a public client which is inherently more insecure than a confidential client, see:

In other words, it is cumbersome, error-prone and less secure… That basically defeats the primary purpose of OpenID Connect for which the starting point is the Authorization Code grant type that allows for simple, zero-crypto (well, apart from TLS) and more secure flows. So I’ve been asked about using a server-side implementation of the Authorization Code grant type with a confidential Client for SPAs. I have added a draft implementation for that to the Apache web server through a so-called “session info hook” for mod_auth_openidc. It then works as follows:

  1. The SPA is served from an Apache webserver that has the mod_auth_openidc module loaded and configured.
  2. Upon accessing the SPA, mod_auth_openidc will first send the user to the OpenID Connect Provider and run through the Authorization Code flow using the confidential Client authentication as configured as a regular web SSO Client. It then creates a application session plus associated cookie on the Apache server for the user who can now load your SPA in his browser.
  3. The SPA can call the session info hook at any time by presenting a valid session cookie to obtain a JSON object with information such as the Access Token, the Access Token expiry, the claims from the ID Token, claims from the UserInfo endpoint etc.
  4. The SPA can extract information about the authenticated user from the session info object for its own purpose and can call APIs in another or the same domain using the Access Token in there.
  5. When the Access Token expires, the SPA can call the session info hook again to refresh the Access Token and mod_auth_openidc will refresh it using a refresh token that was stored as part of the session information.

The end result is that the SPA is using a secure server-side OIDC flow to authenticate the user and obtain & refresh an access token without requiring any crypto or security-sensitive code in the SPA itself! Let me know if you’re interested to learn more:

Thanks to John Bradley, Mark Bostley, Brian Campbell, Jonathan Hurd and George Fletcher for their input.

This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to OpenID Connect for Single Page Applications

  1. > “Apart from some “Identerati” changing their minds about recommending Implicit over Authorization Code with a public Client for this use case”
    Would love to see a post about this. I’m seeing mixed recommendations for SPA (makes sense for native apps), and it’s not clear to me how auth code grant type helps solve issues with SPAs.

    • The basic idea behind using the Authorization Code grant type over the Implicit grant type is that access tokens don’t end up in URLs. This prevents access tokens from showing up in logs, browser history and avoids URL cut-and-paste attacks on them. Of course these issues would still apply to Authorization Codes being passed in the front channel now instead of access tokens but those codes are very-short-lived and one-time usage which makes them less vulnerable.

  2. Pingback: Goal 1 – SPAs –

Leave a Reply

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

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

Google photo

You are commenting using your Google 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