A Guide to Key CIAM Capabilities and Implementation Blueprints (CIAM-Part 5)
This guide outline important CIAM capabilities and effective implementation options. It covers Customer Experiences, Identity and Access Management features, and solutions for Single Page Application (SPA).
This article discusses how adaptive customer-centric customer identity and access management (CIAM) capabilities are essential for digital transformation and integration with emerging digital ecosystems. By dynamically managing customer identities and access across channels, CIAM allows organizations to deliver seamless, personalized experiences across an expanding set of touchpoints. This helps build customer trust and loyalty while streamlining processes like onboarding, authentication, authorization, and identity governance. Well-implemented CIAM also improves security by strengthening access controls and reducing vulnerabilities from outdated or inactive credentials. As digital interactions proliferate, CIAM will remain a core pillar for enabling frictionless customer journeys and maximizing value in an increasingly distributed and connected business environment.
- Its Purpose and Benefits in Today’s Digital Landscape
- Explaining the blueprint for an adaptive CIAM
- CIAM Capabilities for Customer & Experiences
- CIAM Capabilities for Identity & Access (A)
- CIAM Capabilities for Identity & Access (B)
Key Capabilities of Client Identity & Access Management (CIAM) — B
Quick Links:
Identify & Access Management — II
- Authentication
- Session & Token Management
- Stateless and Stateful Tokens
- Authentication & Authorization Protocols
- OAuth 2.0, OpenID Connect (OIDC), JWT Token
- Multiple-Token vs Single-Token Implementation
- Session Control & Management
- Single Page Application (SPA) — OpenID Connect (ODIC) Flow
- Authorization
- Policy Management
- User Profile Management
- CIAM APIs
Other
- Prevention & Control
- Extended Customer Data
Single Page Application (SPA) — OpenID Connect (ODIC) Flow
Single Page Applications (SPAs) are a type of web application architecture where the entire application runs within a single web page. In an SPA, the page does not need to be constantly reloaded as the user interacts with the application.
Instead of traditional server-side page loads, an SPA runs client-side within the user’s browser. As the user interacts with controls on the page, JavaScript code dynamically updates the contents of the page without reloading. This provides a much smoother user experience compared to full page reloads.
SPAs typically use AJAX (Asynchronous JavaScript and XML) or modern JavaScript frameworks like React, Angular, or Vue.js to make API calls directly from the browser. This client-side operation means more secure communication is required to protect users from hackers accessing or modifying these direct browser-to-server requests.
The key benefits of the SPA model are improved user experience through dynamic and fast page updates without reloading, as well as a more app-like feel compared to traditional multi-page web applications. However, the client-side operation also introduces additional security considerations for protecting direct browser requests and responses.
Some of the best practices to consider when implementing a Single Page Application (SPA) with OpenID Connect (OIDC) include:
- Leverage the OIDC framework: OIDC provides a robust platform for modern web and mobile applications. It has the latest security standards built-in to address common cybersecurity challenges.
- Use the Authorization Code flow with PKCE: As per current industry guidance, this is a more secure flow for public clients (e.g. browser-based apps) over Implicit Flows.
- Securely store tokens: When using browser storage, implement appropriate measures to prevent token leakage. Alternatively, keep all security tokens on server-side in secure database.
- Manage User Session: Use secure cookies for session management. Ensure user sessions automatically expire and ensure logouts are implemented.
- Manage Access control: Implement authorization (access control) in the application programming interfaces (APIs).
- Manage token expiry and renewal: Keep access token short-lived. Implement refresh token and keep session alive business logic in backend-for-frontend (BFF).
- Monitor and audit security events: Ensure all user interactions with the SPA and associated API calls are logged appropriately. There should also be automated monitoring processes to detect anomalies and suspicious activities.
SPA — OIDC Implicit Flow vs Auth Code (PCKE) Flow
Two flows are used for Single Page Application namely:
- OIDC Implicit Flow and
- OIDC Authorization Code Flow with PCKE.
Due to security best practices Implicit flow is being phased out in favor of Authorization Code Flow with PCKE. This presentation Oauth 2.0 and OpenID Connect Single Page Application from Dr Philipe De Ryck provides an excellent detail on two ODIC Flows for SPA and differences between Implicit vs Auth Code flows.
Historically, SPAs used the Implicit flow, but best practices have evolved, and the Authorization Code Flow with PCKE (Proof Key for Code Exchange) is not recommended for improved security.
Here are the key differences:
- ODIC Implicit Flow:
Token (ID and access tokens) are returned directly from the authorization endpoint.
Tokens are exposed to the browser’s URL, which can lead to security vulnerabilities.
No client secret is required. - OIDC Authorization Code PCKE Flow:
Uses a code exchange process to obtain tokens securely.
Introduces PCKE extension to enhance security, particularly for public clients like SPAs.
Tokens are not exposed in the URL.
For our blueprint for SPA, we will only discuss OIDC Authorization Code Flow with PCKE.
SPA — OIDC Flow & Refresh Token
An OpenID Connect (OIDC) refresh token is a token that allows an SPA or client (application) to obtain a new access token without a user interaction.
Refresh Tokens are issued by the authorization server along with an Identity Token and Access Token when a user authenticates. OpenID Connect (ODIC) uses the “response_type” parameter in the authentication request to return the desired token, and not all response types support a refresh token. Refer to the table in OpenID Connect (OIDC) Authorization & Token Endpoint section above.
The main purpose of Refresh Token is to allow the client to obtain new Access Tokens without requiring the user to re-authenticate. This keeps the user logged in for longer periods. When an Access token expires or is about to expire, the client (application) can use the refresh token to request a new Access Token from the authorization server without prompting the user to login again.
Here is a typical flow for refresh token:
- Client (application) receives first tokens: When user first login and authenticates, the client (application), depending on response type, it may receive an Identity Token, Access Token and Refresh Token from authentication server. Client (application) stores these tokens securely.
- Client (application) uses token to access protected resource: The client (application) uses the Access Token to call protected resources (e.g. API).
- Token expiration check: Application keeps timer check on expiry of Access token. It has a short time (e.g. 5 min). Before the access token expires, the client (application) will use the refresh token to refresh a new access token without a need for user re-authentication.
- Authentication server issues new access token: The authentication server issues a new Access Token. Refresh Token remains the same. The client (application) replaces their old access token with new one stores them securely. The old access token is invalidated on authentication servers.
- Maximum login session time: This cycle can continue until user has reached the maximum session time allowed to user, after which user is forced to re-authenticate (login again).
Refresh tokens should be securely stored by the client (application), as possessing a valid refresh token means the ability to obtain new access tokens without re-authenticating the user. For server-side applications it is easier to do so, however, for client-side applications like SPA it is a very challenging ask.
If a refresh token is compromised, it can give hacker significant leverage and time to penetrate. Hence, refresh token should be revoked by the authorization server when compromised.
Another technique used to keep refresh token secure is using a feature of CIAM platform called “refresh token rotation”. It’s a mechanism used to enhance the security for long-lived refresh token.
Refresh Token (RT) Rotation
Refresh Token (RT) rotation typically works as:
- In CIAM platform configure the refresh token for “refresh token rotation” with relevant token expiration and rotation interval configurations.
Token Expiration: RT typically have longer expiration time comparing to access token to allow long-lived session and seamless user experience. To mitigate risk of RT leaks, set an appropriate expiration time for refresh token. New RT will be issued after previous one expired.
Token Rotation Interval: This determines how frequently refresh tokens are replaced by new ones. - Client (application) receives first tokens: When user first login and authenticates, the client (application), depending on response type, it may receive an Identity Token, Access Token and Refresh Token from authentication server. Client (application) stores these tokens securely.
- Client (application) uses token to access protected resource: The client (application) uses the Access Token to call protected resources (e.g. API).
- Token expiration check: Application keeps timer check on expiry of Access token. It has a short time (e.g. 5 min). Before the access token expires, the client (application) will use the refresh token to refresh a new access token without a need for user re-authentication.
- Authentication server issues new access and refresh tokens: The authentication server issues a new Access Token as well as a new Refresh Token. The client (application) replaces their old tokens with new ones and stores them securely. The old tokens are invalidated on authentication servers.
- Maximum login session time: This cycle can continue until user has reached the maximum session time allowed to user, after which user is forced to re-authenticate (login again).
SPA — Token Storage Challenges with Single Page Application (SPA)
Storing the refresh token in browser-based applications like SPA is a challenge. There are also secondary issues of token refresh in SPA that concerns security.
Since, its not my focus for this article, I have provided links below from the subject matter experts in this domain. Read following articles to understand the problem and potential solutions:
- Oauth 2.0 and OpenID Connect Single Page Application — Refresh Token (Dr Philippe De Ryck)
- Securing Single Page Applications with Refresh Token Rotation
- OAuth2 Implicit Grant and SPA
SPA ODIC Authorization Flow with PCKE Pattern
The security patterns are constantly changing to protect customers and organization from hackers. While ReactJS has provided great user experiences in browse-based applications, maintaining security in for them is very challenging.
In our pattern, due to security concerns we will use following guidance:
- Firstly, since Implicit Flow is deprecated for security concerns, we will use OIDC Authorization Code Flow with PKCE (Proof Key for Code Exchange).
- Secondly, its virtually impossible to protect the security tokens in browser, hence for our blueprint we will use server-side components to keep token secured.
Finally, proposing two patterns for SPA:
- Pattern 1: Keep short-lived Access Token in the Browser, while rest of refresh token and refresh-token rotation business logic remains in Backend for frontend (BFF).
- Pattern 2: Keep no Access Token in the browser. All of business logic relating to Tokens and integration with Authorization server remains in Backend for frontend (BFF). For Browser, use traditional session control to talk to BFF, and allow BFF to manage all the security Token. This is an idealist solution for security, however, will makes SPA implementation very complex.
SPA Pattern 1 — with OIDC Authorization Code Flow with PCKE
With this pattern 1, the OIDC Authorization Code Flow for SPA works as following:
- Login Initiated: Either User goes directly to login page or is directed to login page when user navigates to the SPA.
Login page may be bespoke Brand’s unique page or provided out-of-box by Authentication Server of Identity Provider. The authentication request includes parameters like client ID, redirect URI, requested scopes, and response type (e.g. “code”). - User Authentication: Users authenticate themselves by entering credentials (e.g. user ID and password). There are many other authentication methods, e.g. social media logins, Multifactor Authentication, Adaptive Authentication, etc.
In third-party applications scenarios, e.g. Linked-in to Twitter, user may also be prompted to authorize the client application to access their identity and requested scopes. - Authorization Code: After successful authentication, Authentication server will send an authorization code and redirect the flow to “redirect URI” specified by client (application) in initial request.
Authorization Code is a short-lived token that Identity Provider (OIDC) issues to client (application) after user successfully login. The client (application) will exchange this token with an Authorization (Access Token). - Authorization (Access Token): Client (Server-side login application) exchanges Authorization Code with Access Token by calling BFF Get-Access-Token API. This BFF API acts as a proxy to implement business logic for Refresh Token. It will call Authentication Server with authorization code. The Authentication Server validates the authorization code and issues the first “Access Token (AT1)” and possibly a “Refresh Token (RT1)”. The token is in JSON Web Token (JWT) Format.
- Store Access Token: BFF Get-Access-Token API will store the access token and refresh token in a database. Typically, it will be a fast-access in-memory database (e.g. Hazelcast, Radis, etc.). It can use session ID and user ID as key to track the refresh token in the dataset. The authentication server also keeps a record of access token and refresh token.
- SPA uses Access Token to retrieve Protected Resources: SPA uses the access token to retrieve protected resources (e.g. API). Access Token is sent in API request. API may verify the token with authorization server using its introspection endpoint. APY may also implement other security measures on scope and authorization to ensure only authorized activities are allow and the data it returns is authorized.
- Token Renewal: If the access token expires, the BFF Get-Access-Token API can use the refresh token to get a new access token and new refresh token without requiring the user to login again. It can use the refresh token rotation feature to get a new refresh token.
Client (SPA application) in this pattern, will neither store refresh token in browser not will it pass it to BFF Get-Access-Token API. BFF Get Access Token API will use its session database to retrieve previous refresh token and use it to call Authentication Server API. Based on Refresh Token Rotation policies, the authentication server will issue second new refresh token and access token and invalidate the previous tokens. BFF Get-Access-Token API will save this token in its session database before returning it back to client (SPA application)
In this case, every renewal of Access Token will force a renewal of Refresh Token. Though its not the ideal process, however, given the sensitivity of keeping security tokens inside of browser for browse-based application like SPA, this may be an acceptable balance. - Session Termination: Session may terminate if user logs out or when maximum session idle time occurs.
Maximum Idle time: The client (SPA application) keeps track of timer and can automatically terminate the session after maximum idle time occurs.
User logs out: If user logs out, the SPA will redirect the flow to logout page. The logout page can communicate with BFF Get-Access-Token API to terminate the session and expire the tokens in authentication server. - Keep Session Alive: In few cases, Client (SPA application) may ping Keep Session Alive API to ensure user’s session doesn’t terminate. This may be required if,
User is active: User is not idle and interacting with site, hence keep session alive. This can happen as SPA don’t often call the backend services when use is interacting with it.
User is idle: User is idle and not interacting with site, then prompt a notice to user and provide a grace period and keep the session alive during that grace period. If user doesn’t respond, then session will time out.
Long running process: A critical task or long running process is running that requires uninterrupted access, hence manually keeping session alive is necessary.
Using SDK for OIDC Flow in React Application
SDK libraries are available to implement Authorization Code Flow with PCKE and refresh tokens in React application. They can handle complexities of token management and session handling, allowing programmers to focus on building application.
- oidc-client-ts Library: It is a modern, typescript friendly library that handles OIDC authentication, including Authorization code flow with PKCE and refresh tokens. It supports OIDC AND OAuth2 protocols. It handles token storage and renewal, including refresh tokens. It also provides session management.
- Auth0 (auth0-react.js) React SDK: If you are using Auth0 as your identity provider, the Auth0 React SDK supports the Authorization code flow with PCKE out of box, including refresh tokens. It provides a custom React hook and other Higher Order Components so you can secure React apps using best practices while writing less code.
The views expressed are my own and do not represent any organization. I aim to have respectful discussions that further positive change as we navigate unprecedented technological transformation. Change is constant, so my perspective may evolve over time through learning, testing, and adapting to new information.