Universal CIAM: Simplifying Identity Management Across Channels and Regions

Introduction

For large enterprises, a robust CIAM (Customer Identity and Access Management) system is expected to serve as a centralised service within the enterprise architecture – supporting multiple channels and regions seamlessly. By functioning as a centralised identity provider, CIAM enables customers to use a single set of credentials across various digital channels, eliminating the hassle of creating and remembering multiple channel-specific logins.

Throughout Midships' extensive experience with CIAM systems in large enterprises, we have observed that a CIAM solution typically emerges alongside a major digital channel product, where the design and implementation of the CIAM solution is often specific to a channel and region.

As the CIAM solution grows organically to support multi-channel and multi-region, its complexity tends to grow and become increasingly difficult to manage – posing significant challenges in maintenance, integrating new systems, and rolling out feature enhancements.

In this article, Midships will share the common pitfalls organisations fall into during the evolution of their CIAM systems and tips that can help you to avoid these challenges.

Separating Product and Identity Onboarding

Many large enterprises combine CIAM-based identity onboarding with product or service setup in their digital channels. This approach leads to customised CIAM implementations that are not easily reusable across channels.

Midships has observed several drawbacks when product onboarding and identity onboarding are not clearly separated:

• Complex Integration: CIAM and channel onboarding services become interdependent, increasing integration complexity.

• Challenging Drop-Off/Return: Since CIAM profiles are not fully created until the end of onboarding, implementing features that allow customers to pause and resume becomes difficult.

• Intertwined De-duplication: Product opening is often an asynchronous process which takes time and requires the customer to come back at a later time to check on the status. As CIAM identity is not being created at this stage, this often involves solutions where channel systems need to interact with CIAM to carryout extra identity de-duplication process, creating extra complexity.

• Multiple Product Complexity: Channels supporting multiple products must manage distinct product opening flows for pre-login and post-login states.

• Difficult Enhancements: Updating or improving the onboarding journey often requires significant changes on both the CIAM and channel sides.

To address these issues, organisations should implement product onboarding as a pure post-login process and handle identity onboarding as a standalone, channel-agnostic operation. From the customer’s perspective, the experience can still appear as a seamless, unified journey—however, the backend design should clearly segregate identity and product onboarding to maintain architectural flexibility and simplify logic.

With the example above, below are the list of benefits organisation can achieve:

• The identity onboarding process can be designed to be channel-agnostic, enabling reuse across multiple digital channels. For instance, this process may include eKYC, the collection and verification of contact details, and the nomination of a username and password. Once identity onboarding is complete, channel-specific activities—such as device registration or product enrolment—can follow as separate steps, tailored to the needs of each channel while maintaining a consistent and streamlined user experience.

• Channels do not need separate flows and implementation for product opening or association before and after login.

• Implementing a drop-off and return feature for product opening is simple since customers are always in a post-login state.

• Aligned channel onboarding with single sign-on across multiple channels, ensuring a consistent customer experience when it comes to identity management.

Favour Local Token Signature and Claims Checking over CIAM Token Introspection

Midships often finds that CIAM is used to validate access tokens during authorisation, where the policy enforcement point (PEP) calls the CIAM API for token introspection. This approach results in over 90% of CIAM traffic being dedicated to token validation, significantly increasing CIAM capacity demands.

As every channel service API now depends on CIAM token introspection, the CIAM team must participate in performance testing and capacity validation for each new channel API release, adding substantial operational overhead. Moreover, as channels decentralise PEP functions, integrating CIAM with multiple channel-level PEPs becomes increasingly complex, making end-to-end regression testing – during upgrades, patches, or certificate rotations – especially challenging.

To avoid these issues, adopt RSA-based access tokens. This allows the PEP to locally validate tokens using a stored copy of the CIAM public key, eliminating the need for direct CIAM introspection and reducing system coupling.

Simplify Session Management

A major source of tight coupling between channels and CIAM occurs when stateful session management – like session idle timeouts and concurrent session control – is handled by CIAM. This forces channel services to constantly validate sessions with CIAM, increasing dependency. Instead, if session management is needed, it should be implemented on the channel side, ensuring that CIAM remains loosely coupled and scalable across multiple channels.

Common CIAM UI for Infrequent Identity Operations

CIAM often operates as a headless service in large enterprises without a UI, meaning every channel must integrate directly with CIAM APIs for identity functions. A redirection or Webview integration pattern can significantly simplify CIAM integration across platforms.

The redirection or WebView integration pattern can follow the standard OAuth 2 flow with the common CIAM frontend application built to react to different themes, locales and devices. This will allow a loosely coupled enterprise architecture that allows CIAM to easily support multiple channels and regions, including Ecosystem integrations such as open banking.

However, for mobile applications, WebView integration may not always provide the best customer experience due to latency when initialising the WebView and loading the CIAM page. Organisations should exercise discretion in determining which CIAM journeys are rendered through WebView and which are implemented natively.

For high-frequency or experience-critical features such as login, a native implementation is recommended to ensure optimal responsiveness and user satisfaction. On the other hand, low-frequency or less critical journeys—such as password reset—can be delivered through WebView to reduce implementation complexity while maintaining acceptable usability.

Common CIAM journeys

More often than it should, CIAM systems are often treated as a system that needs to handle channel-specific requirements. This often results in customising CIAM journeys for each channel and region, creating a highly complex implementation over time.

Instead of treating CIAM as a channel-specific solution, large enterprises should view it as a universal identity service. They should design generic, common CIAM journeys that channels can adopt – while limiting any form of channel-specific customisations. Regional regulatory requirements should not alter the CIAM journey but should be largely limited to the cryptographies used within CIAM and the attributes CIAM are tasked to process and expose. For example, certain regions may require application level encryption for password authentication on top of TLS, this extra encryption requirement for user password can be handled by CIAM for the region however the customer journey for login should remain the the same.

Conclusion

To ensure that a CIAM system efficiently serves multiple channels and regions requires thoughtful design and a clear separation of concerns. Start treating CIAM as a universal identity service rather than a channel-specific solution. If you would like to learn more, please contact sales@midships.io.

Writer’s Overview

Yuxiang Lin – Associate Director - R&D, Midships

Yuxiang leads solution architecture initiatives across Midships, driving innovation in identity and access management platforms. He focuses on bridging business objectives and technology constraints through forward-looking solution design and enterprise architecture excellence.

Short bio: Yuxiang is a solution leader specializing in IAM, authentication and authorization design, and enterprise architecture. He delivers scalable identity solutions that align business and technology goals across Asia, including Singapore, the Philippines, Indonesia, and Vietnam.

📧 yuxiang@midships.io

🔗 LinkedIn: Yuxiang Lin