A Guide to Key CIAM Capabilities and Implementation Blueprints (CIAM-Part 4)

34 min readJun 9, 2024

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.

Key Capabilities of Client Identity & Access Management (CIAM) — A

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

Identity & Access Management

Identity and Access Management (IAM) is a security framework and associated process that manages the identity lifecycle of user identities. This includes managing identities from initial registration through deprovisioning and deletion. IAM regulates who can view or access information, manage data, and execute processes in each system or application.

Key areas that it supports include:

Authentication
Session & Token Management
Authorization
Policy Management
User Profile Management
CIAM APIs

Following is an example of typical authentication and authorization flow for a web application:

Authentication

Authentication is the process of verifying identity of an entity. The identity can be of a user or a system that’s making the calls. In today’s digital environment authentication is a critical process that ensures the security and integrity of customer’s and brand’s data.

There are two key authentication entities:

User to Machine (U2M): Where a user (an actor) is trying to login to system (machine) through a channel (e.g. web, mobile, etc.). Users may be known to brand as customer or guest accounts. Users can also be external to the brand, e.g. in case of partners, vendors, social media users, etc.
Machine to Machine (M2M): Where a system’s process (machine) is integration to another system (machine), e.g. a batch process is calling an API. Systems (Machines) may be internal system of brand, e.g. Ordering System. Systems may be external, e.g. partner systems, vendor systems, or if brand operates as-a-service it may have external systems accessing their APIs.

There are numerous authentication methods each appropriate for certain user cases:

Username and password: This is the most common and traditional method of authentication. Entity is prompted to provide combination of a username and a password. This method is commonly used by websites and mobile applications.
Biometrics Authentication: This method uses user’s biological characteristics e.g. fingerprints, facial recognition, iris scans, voice, etc. This method is often used by mobile applications or IoT smart devices.
Single Sign-On (SSO): This method allows the user to authenticate once and use that authentication across multiple applications without requiring to re-enter credentials.

Centralize Session Management: SSO provides a centralized session management and user authentication services, which allows single-login credentials that can be used across multiple applications.

Internal and External Application: SSO enables integration between internal applications as well as external applications. Most common arrangement includes an Identity Provide (entity responsible for authenticating user and managing the central session) and a service provider (entity that provides an application or API).

Open Standards: The two parties establish a trust by exchanging a security certificate and other configuration information. Open standards are used for interoperability, e.g. Security Assertion Markup Language (SAML), OAuth, or OpenID Connect (OIDC).

Business Critical for Digital Eco System: SSO has become extremely critical in digital channels due to increased availability of white-labelled services through third-party digital partners. These partnerships require fast out-of-box integrations that are enabled by SSO.
Multi-factor Authentication (MFA): This method uses two or more factors to authenticate user. It requires user to provide two or more forms of authentication credentials to verify their identity. E.g. verifying using SMS text on mobile phone, or authenticator app code. This method is now commonly used for authenticating uses on digital channels.

Factors Categories: They fall into one of three categories: 1) Knowledge factors which is something user knows e.g. password, PIN, security questions, etc. 2) Possession factors which is something user has, e.g. mobile device, smart card, security key token, etc. 3) Inherence factors which is something inherent to the users, e.g. biometrics like fingerprint, etc.

Factor Combinations: MFA combines more than one factor to strengthen the security. 1) Two-Factor Authentication (2FA) requires two factors to authenticate, e.g. knowledge factor (password), and possession factor (e.g. SMS code). 2) Three-Factor Authentication (3FA) require three factors to authenticate, e.g. knowledge factor (password), possession factor (e.g. security key), and inherence factor (e.g. fingerprint scan).
Adaptive Authentication: Adaptive authentication is relatively new feature that provides authentication rules that are dynamically executed based on risk scoring. It evaluates multiple factors including contextual analysis, risk, policies, etc. to determine the level of authenticated required for a specific user or interaction.

Traditional methods are static and rely on pre-defined processes. Comparingly, adaptive authentication adapts based on user information, user context, customer journey, and other analysis and risk assessments. Some of the adaptive processes includes:

Contextual Analysis: Gather contextual information about user, channel, device, geolocation, IP location and transaction or activity conducted during the customer’s journey, user behavior patterns, recent interactions, etc.

Risk Assessment: Perform the risk assessments based on the contextual information collected. Evaluate the risk scores based on sensitivity of transaction and likelihood of fraud.

Dynamic Authentication: Based on risk policies configured, apply the appropriate level of authentication process needed. The CIAM then dynamically selects the appropriate authentication method or multi-factor combinations required to authenticate this user.
Delegated Authentication: Also known as “federated authentication”. This method is Typically used for 3rd party authentication for delegated authentication and identity federation. It allows one application (by a service provider) to delegate authentication of users to another trusted source (the identity provider). In this case, the service provider relies on the identity provider to authenticate the users. For example, a user may authorize Linked-in app to access google or twitter API on behalf of the user. Here user is delegating access to Linked-in app to access his information from twitter API.

The authentication supports various channels where Users (customer, partner, vendor, internal staff etc.) interacts with organization. These include:

Traditional Web Applications
Single Page Application (SPA)
Mobile Applications
IoT (Internet of Things) Smart Devices
Social Media Platforms
Customer Service Channels
Offline Channels (e.g. Retail Stores)
APIs & Microservices
Partners and Third-Party Integrations

Authentication Services are design to support a diverse range of channels and interaction points where entity’s (user, machine) identity requires authentication in a seamless manner.

Session & Token Management

Token Management

Token management involves issuing, validating, refreshing, and revoking tokens used for authentication and authorization. Tokens allow for secure integrations between users and systems without exposing private customer data. They are lightweight digital credentials passed around systems. Commonly used protocols for digital channels include OAuth 2.0 and OpenID Connect (OIDC), with OIDC being the most modern protocol. OIDC builds upon OAuth 2.0 to allow for identity verification as well.

Key features of token management include:

Token Creation and Issuance: Initial creation and issuing of tokens when the authorization process initiates.
Token Types: For example, identity, access, and refresh tokens support various use cases in authentication and authorization flows.
Token Format: JSON Web Token (JWT) is now a commonly supported standard format for OpenID Connect flows.
Token Verification and Validation: Verification involves checking signatures and expiry times to ensure the token has not been tampered with. Validation involves checking claims are truthful, such as checking issuer or audience. Validation also checks tokens against a list of revoked or blacklisted tokens.
Token Secure Storage: It maintains a data store for tokens and ensures they are safely kept.
Token Usage and Authorization: When tokens are used by the client (e.g. application), it ensures access is granted based on authorized actions. Tokens are validated against the token store by the authentication server when clients (e.g. applications or APIs) are called using access tokens.
Token Refresh and Rotation: Refresh tokens allow the client (application) to obtain new tokens without requiring the user to re-authenticate. Refresh token rotation is a feature that ensures every time a token is refreshed it is replaced with a new refresh token.
Token Revocation: Tokens have limited lifetimes. They usually expire automatically or upon user logout, or the system may force terminate them in the event of a security breach. This reduces the risk of token leaks.
Token Policies and Controls: This allows defining token governance policies, such as expiration policies, refresh token policies, revocation policies, token validation policies, etc.

Stateless and Stateful Tokens

The CIAM tokens can be either stateless or stateful, depending on the requirements of clients (applications).

Stateless Tokens:

Stateless tokens are self-contained and include all the necessary information for user authentication or authorization. They do not require session management. They are typically used for machine-to-machine scenarios where user sessions are not involved. Therefore, they do not store any user session state on the server side. They are more scalable as they do not require server-side storage for session data.

Use cases for stateless tokens:

Stateless machine-to-machine (m2m) APIs: Stateless tokens provide authentication for APIs/Services where user sessions or user-context are not involved, typically in machine-to-machine scenarios.
Public (non-secure) applications: Public applications that do not require user accounts and where no session state is maintained, like public web pages in Single Page Applications (SPA).

Stateful Tokens:

Stateful tokens include the user’s session state that is maintained on the server. They carry a session ID to retrieve the user’s session state from the server. They store user session/state information on the server side. They are typically used for user-to-machine scenarios where user sessions are involved, like secure websites or mobile applications.

Use cases for stateful tokens:

Multi-factor authentication (MFA): MFA authentication flows that require maintaining session state on the server.
Backend stateful processes or workflows: Transactions or workflows that orchestrate business processes and need state information. For example, provisioning flows for mobile service activations.
Secure applications & APIs: They are commonly used for secure applications and SPAs that need to track user sessions to enforce logins/logouts and support personalization. Backend for frontend (BFF) APIs or Personalization APIs that need to track user session context can also use stateful tokens for contextualized responses based on user context.

The appropriate architecture for a stateless or stateful token depends on evaluating the client application’s specific needs and constraints. Key factors to consider include the requirements for session management, desired level of security, compatibility with existing systems, performance objectives, and data storage requirements. A stateless token may be preferable for simple authentication without session state, while a stateful token could enable storing additional user attributes or session data as needed. The architecture choice should aim to meet the functional requirements while balancing security, maintenance effort, and integration complexity.

Authentication & Authorization Protocols:

The two main authentication protocols relevant for our token-based authentication blueprint are OAuth 2.0 and OpenID Connect (OIDC). OAuth 2.0 focuses on authorization, allowing clients access to server resources on a user’s behalf. It is commonly used to manage API access. OIDC builds on OAuth 2.0 by standardizing ways to verify user identity and authentication in addition to authorization. OIDC enables single sign-on capabilities across multiple applications.

In summary, OAuth 2.0 is best suited when only authorization to resources is needed, such as for API access. OIDC provides additional identity verification and single sign-on that is useful when user authentication and identity across multiple applications is important. For our blueprint, we should evaluate our specific security and user experience requirements to determine whether OAuth 2.0 or OIDC is the most appropriate protocol.

OAuth 2.0

Open Authorization 2.0 (OAuth 2.0) is an open standard protocol that enables authorization without sharing user credentials like passwords. It allows “users” to “grant” third-party applications access to their data, such as photos or email, without having to hand over their login credentials.

OAuth 2.0 focuses specifically on authorization, not authentication. During authentication, a user proves their identity by providing credentials like a username and password. Authorization determines what data within an account the third-party app is allowed to access.

The key aspect of OAuth 2.0 is that it generates an access token that allows an app limited access to a user’s data without knowing their password. This token implementation is widely used by web and mobile applications to securely authorize access to a user’s data on other sites and services, enhancing security and user convenience compared to handling credentials directly.

An OAuth 2.0 Access Token contains important authentication and authorization data. This credential is issued by the authorization server to grant a client (application) access to protected resources, such as API endpoints or user data. It allows the client (application) to make requests to the resource owner’s protected resources without needing the resource owner’s credentials. Access tokens are usually short-lived and can be revoked if compromised.

The main piece of information included in the OAuth 2.0 Access Token is:

Resource Owner: The resource owner (e.g. user) refers to the person or entity who owns the protected resources, such as data or APIs. In OAuth, the resource owner authorizes third-party applications or services to access their protected resources by granting permission to those applications. For example, a user (the resource owner) may grant a social media application access to their profile data or ability to post on their behalf. The resource owner must explicitly consent to the access being granted to the third party.
Client: A third-party application which is requesting access to certain user resources and data in order to provide its services. However, users should be aware of what specific permissions are being requested and feel comfortable with how their information may be used or shared before granting approval.
Authorization Server: The authorization server is responsible for authenticating the resource owner (i.e. user) and granting authorization to access protected resources to the client (application). It authenticates the resource owner (e.g. user) and obtains authorization to access their protected resources. This is usually done via an authorization code or implicit grant flow where the user reviews and approves the client application’s access. Token is issued to the client (application) after successful authorization from the resource owner.

The “access token” represents the authorization granted to the client (application) to access specific parts of the protected resources on behalf of the resource owner (e.g. user).
Resource Service: It is the server that hosts the protected resources, such as data or APIs, that a client (application) seeks to access on behalf of resource owners (typically users). The resource service protects access to its resources by requiring authorization from an authorization server after the client (application) obtains permissions (scopes) from resource owners.
Authorization Grant: An authorization grant represents a resource owner’s consent for a client (application) to access protected resources on their behalf. It allows the client (application) to obtain an access token to act as the resource owner for specific scopes or permissions. Common authorization grants used in OAuth 2.0 include authorization codes, refresh tokens, client credentials, and implicit grants. The authorization grant is issued to the client (application) by the authorization server with the approval of the resource owner (e.g. user). It establishes the scope of the permissions granted and prevents unauthorized access to the protected resources (e.g. Data or API).
Redirect URL: The redirect URL allows the authorization server to securely redirect the resource owner’s user-agent (typically a browser) back to the client application after access is granted or denied. The authorization server will redirect to the registered redirect URI provided by the client and include parameters like an authorization code or access token. This allows the client (application) to complete the authorization process by exchanging the authorization code for an access token from the authorization server, enabling it to call protected APIs on behalf of the resource owner.

OAuth 2.0 provides the following commonly used flow types:

Authorization Code Flow: Suitable for web applications (e.g. user-to-machine) to obtain authorization from the resource owner (i.e. user), using an authorization code or access token. This flow allows the client to securely store client secrets.
Implicit Flow: Suitable for browser-based and mobile applications (e.g. user-to-machine) where the client (application) cannot securely store client secrets. It skips the “authorization code exchange step” and directly issues an access token to the client (application).
Client Credential Flow: Suitable for confidential clients (e.g. servers or machine-to-machine) to obtain an access token based on the client (application) credentials, without using the user’s authentication.
Resource Owner Password Credential Flow: Provides a flow for the client (application) to directly authenticate the resource owner (i.e. user) to obtain access tokens using the resource owner’s (i.e. user’s) “username and password”.

OpenID Connect (OIDC)

OpenID Connect (OIDC) extends and builds upon the OAuth 2.0 framework to provide a standardized way to authenticate (identify) as well as provides authorization (access) in a single protocol. Comparingly, OAuth 2.0 only provide authorization (access).

OIDC defines “identity tokens” that allow clients to verify the identity of end-users. These tokens are used by clients (applications) to authenticate end-users via an authorization server, while also obtaining basic profile information about the end-user. It also supports optional functionality like requesting user profile information from the authorization server.

By extending OAuth 2.0, OIDC enables clients to verify the identity of the end-user (instead of just obtaining an access token) as well as to obtain basic profile information about the end-user. This makes OIDC useful for both authentication and authorization use cases on the web and in mobile and desktop applications.

OpenID Connect (OIDC) provides several key features including:

User Authentication: OIDC allows clients (applications) to verify a user’s identity by authenticating them. It supports various authentication methods like username/password, multi-factor authentication (MFA), and social logins (e.g. Google, Facebook).
Authorization Flows: Allows clients (applications) to choose from common authorization flows like Authorization Code Flow and Implicit Flow to implement authorization in their applications. This provides flexibility in how users can authorize access to their data while maintaining security and compliance with security standards.
Identity Tokens: OIDC introduced Identity Tokens, which are JSON Web Tokens (JWTs) that contain identity information about authenticated users. Identity Tokens allow clients to verify the identity of users without making additional calls to the authorization server to retrieve user information. They provide a way to securely transmit user identity attributes and claims between an authorization server and a client (application).
Identity Token Validation: It verifies the integrity and validity of an identity token. This includes checking the token’s signature to prevent tampering, as well as validating the expiration, subject, and issuer listed in the token’s claims. This helps prevent unauthorized access using invalid or forged tokens.
User Information Endpoint: It allows authenticated clients (application) to retrieve additional profile details about the logged in user, such as name, email address, profile photo, and other customizable profile fields.
Discovery Endpoint: It allows clients (applications) to dynamically obtain metadata about the authorization server, such as the authorization endpoint URL, token endpoint URL, issuer identifier, and JWK Set URI. Hence, clients (applications) no longer need to be hardcoded with this configuration information. It simplifies application development.
Session Management: OIDC session management extension allows clients to use refresh tokens to obtain new identity tokens after the initial authentication, without requiring the user to re-authenticate. This allows clients to maintain authenticated sessions for longer periods of time.

OIDC session management extension allows client applications to maintain authenticated user sessions for extended periods without requiring re-authentication from the user. It does this using refresh tokens. For authorization code flow or implicit flow, OIDC issues both an ID token and a refresh token. The ID token contains claims about the authenticated user and is short-lived, expiring in a few minutes. The refresh token has a longer lifetime, typically several hours or days.

When the ID token expires, the client (application) can use the refresh token to request a new ID token from the authorization server without involving the user. This allows the client (application) to maintain an authenticated session without interrupting the user’s workflow.
Single Sign-on (SSO): SSO capabilities are provided by OIDC through the use of Identity Tokens and session management, allowing a user to authenticate once and have that authentication apply to multiple applications. With SSO using OIDC Identity Token, once it is validated by an initial client application, a session is established for the user. Subsequent requests from that user to other client applications within the same SSO domain that also comply with OIDC can then reuse and recognize this established session, removing the need for the user to re-authenticate or login again when accessing any other related applications under that SSO configuration.
Refresh & Revoke Token: It provides mechanisms that allow tokens to be renewed as needed to extend their validity and also revoked as needed to terminate their validity before expiration, ensuring tight control over the lifecycle and usage of issued tokens.
User Consent and authorization: OIDC includes features for user consent and authorization that help ensure users maintain control over their personal data. It allows users to grant or revoke consent for a client (application) to access their data. This gives users control over how their information is used by different applications.
Standard Claims: ODIC provides standard claims as published (OpenID Connect Scopes and OpenID Connect Standard Claims)
Scopes: Scopes allow clients to specify what level of access they need to the user’s information and resources. Some common OIDC scopes include:

openid: This scope indicates that the client is making an OpenID Connect request. It must be included in requests for access and ID tokens.

profile: This scope allows access to basic profile information about the user such as name, email, and profile picture.

address: This scope allows access to the user’s physical address information.

By specifying scopes, clients (applications) can control the level of access granted by the user during authentication. This allows users to consent to only the data and resources that are necessary for a particular client (application), improving privacy and security.
Token Format: Token uses standard JSON Web Token (JWT) format.

ODIC Flows: OpenID Connect (OIDC) provides the following commonly used flows. These are like OAuth but use JWT tokens with OIDC claims standards:

Authorization Code Flow (With PCKE): Like OAuth 2.0 but uses JWT Token. Proof Key for Code Exchange (PCKE) is recommended to prevent authorization interception attacks.

Use Case: This flow is used for Traditional Web Application on Server-side. It is also now recommended for Single Page Application (SPA) through server-side components. See SPA section later.
Implicit Flow (With PCKE): Like OAuth 2.0. It is deprecated in favor of Authorization Code Flow (with PCKE). It was designed for browser-based applications (e.g. SPA) that can not securely store client secrets. It returns Identity Token directly to client (application) in the browser, but that made it much less secure than Authorization Code flow.

Use Cases: Legacy Single Page Applications (SPA). It should be treated as tech-debt and replace with Auth Code flow.
Hybrid Flow: It combines the authorization code flow and the implicit flow enabling the client to receive both Identity Token and Access Token in first response. This allows the client (application) to directly use the access token from the first response. This can make it easier for applications to call APIs.

Use Cases: Application that require both Identity Token and Access Token.
Client Credential Flow: Suitable by confidential clients (e.g. servers or machine-to-machine) to obtain access token based on client (application) credentials, without using user’s authentication.

Use Cases: Machine-to-Machine (M2M) integration.
Resource Owner Password Credential Flow: This uses traditional username and password of login screens. OIDC provides a flow for client (application) to directly authenticate the resource owner (i.e. User) to obtain access tokens using the resource owner’s (i.e. User) “username & password”.

Use Cases: Legacy Applications

Which Flow to use — Auth Code or Implicit

The selection of the appropriate OpenID Connect (OIDC) flow depends on several factors. These include:

Client requirements (such as for web-based, mobile, or single page applications)
Desired level of security
Nature of the user experience

Different OIDC flows offer trade-offs in these areas. Choosing the flow requires considering the specific needs of the client application and users. Factors like security, user experience, and client type all influence which flow may be best suited.

Implicit flows are deprecated and discouraged due to security concerns. This has made the choice easier, i.e. Authorization Code Flow with PKCE is now a standard for web-based, SPA, and mobile app.

Implicit flows are deprecated and discouraged due to security concerns. The Authorization Code Flow with PKCE is now the standard approach for web-based, single-page application (SPA), and mobile applications. This choice has become easier as implicit flows pose security risks and are being phased out. The Authorization Code Flow with PKCE provides stronger protection of client secrets and is recommended for all new integrations.

Digital security is rapidly evolving. Solution architectures must be designed to adapt to future changes. When building solutions, architects should strive to develop architectures that can adapt to future security updates and innovations. Flexibility and extensibility should be key considerations so that solutions don’t become outdated too quickly.

OpenID Connect (OIDC) Endpoints

OpenID Connect (OIDC) authorization has several endpoints, including the following endpoints:

Authorization Endpoint (/authorize): This is used to initiate the authentication process. Client (application) redirects user to this endpoint to request authorization. Users enter their credential and on successful authentication client receives an authorization code from authentication server.
Token Endpoint (/token): The endpoint is used by client (application) to exchange authorization code or refresh tokens (e.g. Identity Tokens and Access Tokens)
User Info Endpoint (/userinfo): The endpoint is used by client (application) to retrieve additional information about the authenticated user.
Terminate Session Endpoint: This is an optional endpoint that allows users to log out from the client (application) and remove the sessions from the authorization server.
Discovery Endpoint (/.well-known/openid-configuration or /openid-configuration): Used by clients to discover OIDC provider endpoints and keys.

OIDC Response Types

The OIDC authorization endpoint supports the standard response types defined in OAuth 2.0 plus some additional types that return ID tokens containing user information. It supports the following response types:

This article on medium explains commonly used OpenID Connect Flows and type of tokens returned by request types: Diagrams of All The OpenID Connect Flows.

JSON Web Token (JWT)

JSON Web Token (JWT) represents the format of a token commonly used by OpenID Connect & OAuth 2.0 framework. JSON stands for JavaScript Object Notation. JSON is a lightweight format for storing and transporting data. JSON is commonly used format for modern Restful API interfaces.

JSON Web Token (JWT) provides following features:

Token Sections: The token contains 3 sections: <header>.<payload>.<signatures>

Header: Header section provides the meta data. Typically contains the token type (JWT) and the signing algorithm being used, such as HMAC SHA256 or RSA.
Payload (Claims): Contains the claims. Claims are statements about an entity (typically, the user) and additional metadata.

Signature: — Used to verify that the sender of the JWT is who it says it is and to ensure it hasn’t been altered.
Self-Contained: JWT token are self-contained and include all the necessary information about user, identity, access, etc. This means that the client (application) doesn’t need another data source or database to lookup for this information.
JSON-Based Format: JWT uses JSON (JavaScript Object Notation) as its payload. It’s a common format used by Restful API interfaces.
Session Info: JWT tokens do not directly maintain session state. However, they contain claims like the user ID, session ID, and session expiration time that allow client (applications) to maintain user sessions.
Signature for Security: JWT tokens are digitally signed using crypto algorithms like HMAC or RSA. This ensures the integrity of tokens from unauthorized tampering.
Claims: The Payload section of JWT contains properties that are called “claims”. These are properties about an entity (e.g. user) and other data related to token, e.g. client_id, exp (expiration time), iss (issuer of the token), etc.
Encoding and Decoding: Applications can decode the token using Base 64 encoding. The encoded token can be examined using jwt.io.

**Figure:** Example of the format of JWT Token (jwt.io)

JSON Web Token (JWT) has two types of claims:

Registered Claims: Standard claims registered with the Internet Assigned Numbers Authority (IANA), e.g.,

iss (issuer): Issuer of the JWT
sub (subject): Subject of the JWT (the user)
aud (audience): Recipient for which the JWT is intended.
exp (expiration time): Time after which the JWT expires.
nbf (not before time): Time before which the JWT must not be accepted
iat (issued at time): Can be used to determine age of the JWT.
jti (JWT ID): Unique id; used to prevent the JWT from being replayed.
Custom Claims: They are non-registered. They can be public or private claims. They are optionally used for specific scenarios in given organizational architecture.

Public Claims: They can provide additional data properties (Property names that are not governed by standard registered claims). E.g. user role, or custom metadata relevant to specific organization.

Private Claims: They are intended for private use-cases within the context of the application. The properties are typically prefixed with an underscore (_) to distinguish them from registered or public custom claims.

To learn about OpenID Connect (OIDC) standard claims refer to,

Multiple-Token vs Single-Token Implementation

OpenID connect (OIDC) provides the choice between using multiple tokens or a single token depending on the specific requirements and architecture of the application. The difference between the two implementations are following:

1. Multiple-Token Implementation

Identity Token: This token represents that user was successfully authenticated and has the rights to login. It was first introduced by OpenID Connect (OIDC). It contains information about the authenticated user, such as user ID, name, email, address, and other claims. It is typically used by client (application) to verify user’s identity.
Access Token: This token represents that the user is authorized and granted access to the client (application) and have access to protected resources (e.g. webpage or API) on behalf of the user. This token is used to make authenticated requests to backend services or APIs.
Refresh Token: This token is optionally used to support long-lived sessions. The client (application) used the refresh token to obtain new access token without requiring the user to re-authenticate. It improves the user experience by reducing the frequency of login.
Pros: By keeping identity and access token separated, it can mitigate certain security risks. For example, if one token is compromised, then it doesn’t necessarily compromise another token.
Cons: It creates increased complexity in implementing multiple tokens in client (application) as the application must handle multiple tokens and maintain their validation and revocation processes. It is also noticed by development community that it can be very confusing to understand the difference between two tokens and implementing this pattern.

2. Single-Token Implementation

Combined Token: In single-token implementation, the JWT token contains both user identity and access information combined in a single token. The claim section of the token includes identity claims (similar to Identity Token) and access claims (similar to access token).
Pros: Simplifies implementation by reducing number of tokens needed by client (application). It also reduces the overhead of token handling and verification.
Cons: Limits flexibility in token usage and validation by tightly coupling two tokens together.

In summary, while multiple-token implementations offer higher security, granular control, and scalability benefits, they also introduce complexity, overhead and token synchronization challenges. On the other hand, while single-token implementations offer simplicity, reduced overhead, and ease of implementation, they also pose carry certain security risks, and reduced flexibility.

Organization should carefully consider these pros and cons based on their security needs and specific application requirements.

Multiple-Token Implementation

A good use of multiple-token implementations is when there is third-party Identity Providers (IdP). In that context, multiple tokens can be used for Identity Token (Authentication Token), and Access Token (Authorization Token). Many social providers are using this kind of authentication, e.g. Google, Facebook, etc.

Identity Token or ID Token (Authentication Token)

Following is the flow for getting an Identity Token:

When the user logins the OpenID provider issues this token. This is a basic token that verifies that the user has successful credentials to login to the application, and that application can trust the user’s identity. The Identity Token’s payload contain “claims” may add additional information e.g., user id, name, or email, etc.

Access Token (Authorization Token)

Is the token that gives an application delegated access to a protected resource. In the example below, a client (application) wants to get access to protected resource (e.g., API).

After the user has successfully logged in (in previous example) and has the Identity Token, the application needs to fetch the data from protected resources (e.g., API). It requests the authorization server to provide access token. The authorization server issues an access token, after successfully authentication the user. For example, user may authorize Linked-in app to access google or twitter API on behalf of the user. Hence, user (who is the owner of protected resource) gives a delegated access to Linked-in App to publish user’s linked-in post to their twitter account.

This “authorization” is limited to certain actions. These actions are controlled through “scope” mechanisms. Scopes allow the user to authorize a 3rd party application to perform only specific operations, in this delegated access.

Note: Delegated authorization in OpenID Connect implementation means authorizing a third-party application to access a resource on behalf of a user. Access Tokens are specifically used for delegated authorization and access.

In this case, the “API” also needs to understand these “scopes” mechanisms in the token and implement the authorization or access control to perform relevant actions that are authorized by the user. The implementation of these access token can be confusing, as the authorization decisions based on access token format (scopes and claims, etc.) will depend on many factors. The meta data needs to be defined and understood by both the authorization server and the resource (e.g. API), and resource needs to interpret it correctly to implement authorization decisions.

The Access Token’s payload may add additional information e.g., scope. Scope can be string of scope-names e.g. “profile”, “product”, or “account balances”. This is indication that user has only granted authorization for these domains.

Multiple-Token End to End Flow

Let put the end-to-end multiple token flow in single diagram to get better understanding:

**Figure:** Identity & Access Token flow

If we apply the earlier flow of a typical web application (provided above) in this article:

1. User is authenticated on a login screen and issued an “Identity Token” after a successful attempt. It tells the application that user is trusted.

2. However, the web application itself may not render anything yet, as it needs to fetch data from set of APIs to get more information on user, e.g., product information, access rules to inform what actions user is allowed to perform, etc.

3. Application needs to get second “Access Token” to fetch the data from API. It will request an access token from Authorization Server, then make a call to API using access Token.

4. Authentication Sever needs to ensure that application requesting an Access Token, has a Trusted user logged in, and its session is still active before issuing a new Access Token.

5. The Access Token needs to include information on user’s identification and its session information to process the web application’s request. This is because sessions are related to User login and Logout. This means that Authentication server needs to keep track of Identity token and its associated user session and other user context before issuing an access token.

Where, Authorization Server can not include this information, it will become onerous on API to receive user credentials and session related information.

6. API will have to implement “scope” in a three-way relationship between user, web applications and authorization server, which can be very confusing. API will need to ensure that it doesn’t perform any action not authorized by the user, and it doesn’t return any data back to web application that user is not entitled to.

One a side note, often, in traditional applications, the entitlements are implemented directly into the application layer and API return the data back to web application based on security trust. This is a poor implementation. In a large enterprise with many applications, developers will repeatedly implement entitlement business rules related to access control in each of the application. In a proper implementation, this access control must remain at API layer reducing the redundancy of maintaining these access rules by each application.

In an enterprise application, where both application and API both are controlled by enterprise (and no 3rd party IdP is involved, like in case of Linked-in/Twitter), then in this scenario both Application and API can be treated as one. This scenario is known as “First Party Authorization”. In this scenario, the API may use Identity Token or Combined Token to call the API. For more information, refer to First-Party and Third-Party Applications.

The key benefit of this pattern is that the Identity Token is kept separated from Access Token and keeping their respective security concerns separated out. It fits the use case of Third-Party application using OpenID Connect. The reason given, based on OpenID connect example is,

o Identity Token doesn’t have “authorization” information (i.e. scopes). It doesn’t state what application can do on behalf of the user.

o The user has not given consent to the application to use Identity Token for authorization purpose.

However, for First-Party Applications (when application and API both are controlled by same entity), where protected resources (e.g. API) needs to make authorization decisions based on User’s identity and session, then that information be provided in Access Token JWT (as a single token).

References:

It may be confusing to understand multiple-token implementations, therefore, following video presentations are helpful to understand the concepts:

Single Token Implementation

A single token implementation is more suitable for First-Party Application scenario, e.g. where both Application and API are controlled by same enterprise, and there are no 3rd party Identity Providers (IdP) involved. In this example, a web application and API can be seen as one. Then the same Token can be used for Authentication and Authorization (Identity Token & Access Token).

CIAM platform provides the use of a single token both Identity Token and Access Token to support these scenarios. It is called token consolidation or token convergence. This approach improves the interoperability between authentication and authorization process and makes it simpler for service providers (e.g. web applications) to implement the Token in their respective applications.

In the converged token approach, both authentication and authorization information are included in same token payload. For our discussion here, the Access Token’s payload may include both identity and access information, i.e., Identity information (e.g. name, email, scope, etc.), authentication (e.g. authentication method, timestamp, etc.), authorization (e.g. scopes, permissions, etc.).

Numerous platforms support Token convergence (for combined token) through custom claims and scopes including:

Auth0: It supports it through customizable rules engine to allow custom claims to JWT Tokens.
Okta: It supports it through Authorization Server features to allow custom claims and scopes to JWT Tokens
ForgeRock: It also supports it through additional claims feature.
Ping Identity: It supports it through token customization features.

Benefits of single-token implementations:

This approach offers several benefits:

Simplified Token Management: The applications need to program single token for both authentication and authorization. It reduces the complexity, error handling, logging, testing and maintainability of the software application.
Improved Interoperability: It improves the interoperability between authentication and authorization process. Single Token has same format that can be used across different systems and API.
Simpler to implement: The applications don’t need to implement incremental processes to repeatedly acquire separate access token. The downstream services or APIs don’t need to additional complexity to find user context and validate user identities.

Single-Token End to End Flow

User Authentication: Users authenticate themselves using credentials (e.g. username and password) through the first-party application. The application sends these credentials to the CIAM system’s authentication (API) endpoint.
Token Issuance: CIAM system verifies the credentials and upon successful authentication, it issues a single token (usually a JWT Token) that contains all necessary information for the user session. This approach is called token consolidation or token convergence.
Token Storage: The JWT is sent back to the client application in the response. The token is stored client-side (usually in browser cookie or local storage) and is sent with each request to the server to validate the user session.
Token Usage: For each subsequent request, the client application includes the JWT in the HTTP headers (usually the ‘authorization’ header with the value ‘bearer <token’). The server extracts the token from request header and passes it to the CIAM system for validation.
Token Validation: The CIAM system validates the token, checking its signature, expiration, and claims.

If the token is valid, the server processes the request and returns the appropriate response.

If the token is invalid or expired, the server returns an authentication error, prompting the user to re-authenticate.
Token Expiry & Renewal: Token typically have a short lifespan for security purposes. When token is about to expire, the CIAM system can use a refresh token (if implemented) to issue a new JWT without requiring the user to re-enter their credentials.

In simpler implementation, users might be prompted to login in again once the token expire.

Session Control & Management

Managing application sessions with CIAM and other external Identity Providers (IdP) can be very challenging. There can be many parties involved including multiple applications that provides overall customer experience. Many enterprises don’t have Single Sign On (SSO) capabilities implemented, and it create further problems in maintain control of User’s session.

A session signifies that “user” has logged into Brand’s channel, e.g. website, mobile app, etc. The session is valid for a defined period during which user can perform set of interactions based on their access level. These interactions are delivered to user through journey experience applications. After the successful login, user can perform multiple interactions and activities, e.g. viewing their account balances, make payments, change their profile, etc. An application can be Java/JSP or .Net Web Application, Single Page React (SPA) application, Mobile Application, etc. For Instance, for traditional JAVA Web apps their sessions were maintained by their application servers like WebLogic or WebSphere. However, in React SPA there is no application server level session. Hence, it makes it more challenging.

Session Layers:

There are three session layers involved that are created after user logs in:

Application Session Layer: Internal session management of the application. Each application tracks their user session information. Where there are more than one application delivering overall experience, often they build internal stores to manage their session information that may be shared with other participating apps.
Authorization Server Layer: Authorization Servers, e.g. OKTA auth0, PingFederate, etc. The Auth Server store user information after successful login. This session layer provides the capabilities to implement Single Sign on (SSO).
Third-Party Identity Provider Session Layer: Within Brand, there may be only 1 identity provider which is brand itself. However, if user attempts to sign in with other IdPs like Google, Facebook, Twitter, etc. they use external credentials that IdP will authenticate.

When user successfully logs in, a session is created (in each of the session layers). Session will last until a set expiration time, or user logs out, or session cookie is removed from the user’s browser. If user is idle session will time out automatically after expiration date. If user is not idle, then a “keep session alive” function will be executed to ensure that user’s session doesn’t time out and continue to get extended. Authentication Servers provide API to refresh-token without needing to re-login. These refresh-token functions are used to keep session alive.

Where there are many participating applications with each its own session management, it may complicate managing in-session information and end to end flows. A session created in authentication server session (session layer 2) acts as centralized session management. Hence, applications can make use of this central session identifiers to keep track of user session information and redirect users to login pages after the central SSO token has expired.

Common Session Functions

Session Login: Once the user is authorized, user’s session is initiated. As we have mentioned earlier that depending on organizations’ implementation there are 3 session layers. Each of these layers maintains user’s session information. Some applications maintain their own local tables to identify session records, other uses out-of-the-box CIAM platforms to maintain session records.
Session Timeout: Usually, a 15–30-minute session timer is initiated after successful user /login. If user remains Idle for that long the session will timeout and user will not be able to do further interaction without going through a new Sign-in process. Few key parameters to maintain session are:

Maximum Session Time = Maximum Session Time allowed to user (e.g. 30 minutes), after which if user is still active a Session Refresh is required.

Maximum Idle Time = Maximum Idle time for user’s inactivity after which session will timeout. E.g. 15 minutes.

However, if user continues to interact with the site or application the session will remain active.
Session Keep Alive: In web or mobile application, session keep-alive function is used to prevent user from timing out. Application will use keep-alive function to send request to server in the background. This function keeps the session alive by resetting the session timer. Few use cases are:

User is active: User is not idle and interacting with site, hence keep session alive.

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.
Session Refresh: It is typically used to maintain user session for longer period without the need for frequent re-authentication. It still ensures security by refreshing the tokens. This process is commonly used in web applications that use token-based authentication system, e.g. JWT, OAuth2.0, or OpenID Connect. Few use cases are:

Maximum Session Time: Typically, when a maximum session time is completed then a session refresh is required to extend the session.

Single Sign On (SSO): where use has access to multiple applications, the session refresh ensures that the user remain authenticated across all the allocation using the SSO during that session.

Token revocation handling: where tokens can be revoked for compromised tokens
Session Data: During the session, application stores information about user’s session during their interaction with a digital channel (e.g. web). This data is associated with session_id and remains the session cache until user’s session is active. Application saves session data in browser session, on server site application server’s cache, or in a database, etc. The in-memory databases are most suitable of session cache due to their faster access and speed. The session data automatically expires and purged after user’s session is terminated.
Session Logout: Logout is the process of termination user’s authentication session. Once the session is terminated, user can no longer perform interaction or activities (on a given site) and is redirected to re-login again. Session needs to be terminated in all three session layers.
Application Session Layer: If all applications are using common internal session store, then clear or deactivate the session entries. If there are more than one application that uses their own individual session tables, they all will need to be cleared. In some cases, they may have been programmed to auto-time out after certain interval.
Authorization Server Layer: Authorization Server platform provides APIs that can be called to logout. A redirect-URL can be provided. The logout API will clear the session and redirect the flow to provided redirect-URL.
Third-Party Identity Provider Session Layer: Its optional to terminate the session with 3rd Party IdPs. Where IdPs provided an API service to logout users, then it can be used to terminate the session.

Centralized Session Management

CIAM can enables unified control and monitoring of user sessions across multiple applications (e.g. websites) within a secure environment. This approach ensures consistency in session handling, improves security, and enhances the user experience by allowing single sign-on (SSO) and centralized session termination.

Key components of centralized session management are:

Single sign-on (SSO): It supports unified authentication across multiple applications without needing to log in separately to each one. After the authentication, a token (e.g. JWT) is issued and used across different applications to validate the user’s identity.
Centralized Session Store: It provides a centralized repository that stores session data, such as user IDs, session token, expiration times, last activity, and other related information. The session store is updated in real-time to reflect the current state of all user sessions.
CIAM Services: The Authentication Server manages user authentication, token issuance, and validation. Session Management Service handles the creation, validation, and termination of session across all applications. This allows CIAM to:

Session Termination: CIAM can terminate a user session centrally, immediately invalidating the session across all applications. This will trigger a user logout and expire the user session.

Session Monitoring: CIAM can continuously monitor active sessions and it can enforce policies such as session timeout, inactivity limits or other risk and fraud controls.

Session Renewal: CIAM can issue a new refresh token if session token is about to expire without requiring user to re-authenticate again. In some cases, CIAM can also force user to re-authenticate to renew their session, depending on the security policies.

Next: CIAM Capabilities for Identity & Access (B)

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.