OAuth 2.0 SSO with single-page applications - a configuration example

Using single-page applications (SPA) in OpenID Connect setups poses some security risks since web browsers insufficiently protect access and refresh tokens.

In this configuration example, we demonstrate how Airlock Gateway and Airlock IAM can be configured to protect access and refresh tokens issued by a third-party authorization server from being stored in the browser.

Solution overview

  • The solution will use the following components:
  • The authorization server supports the standard OpenID Connect authorization flow.
  • The Airlock Gateway receives and stores access tokens.
  • Airlock IAM acts as an OIDC client towards the authorization server.
  • The SPA has an authentication session with the authorization server.
  • The SPA receives session cookies from Airlock IAM.

The following sequence diagram details the authentication flow:

API Service authorization over OAuth 2.0


This configuration ensures that a target application receives the access token issued by the authorization server with every request made by the SPA.

  1. Configure at least one of the following Flow Client Settings:
    1. Airlock IAM as OAuth 2.0 client configuration details
    2. Airlock IAM as OIDC client configuration
    3. Airlock IAM as OIDC client with discovery configuration
  2. Airlock IAM is configured as a client towards a remote authorization server.
  3. Configure the Authentication Flows settings:
  4. Airlock IAM now has a Target Application and an Authentication Flow that will use the previously configured OAuth or OIDC client.
  5. Configure the Flow UIs:
  6. Airlock IAM will now present a UI during the interaction with the user for the previously configured target application.
  7. Airlock IAM now supports authentication with a remote authorization server through the Loginapp UI.


  • Known limitations of this setup are:
  • This setup only works with access tokens. Airlock IAM as a client does not support refresh tokens.