Architecting a Modern CIAM Solution

Reading Time: 10 minutes

The diagram below illustrates the various interactions in a typical B2C or B2B SaaS solution, depicting Users and Services, the front-end (browser) interfaces for SPAs, classic Web Applications, Mobile and Desktop Apps, together with the participation of Backends, BFFs and APIs.

Managing customer identities and ensuring secure access in such scenarios has become a key challenge for organisations developing B2C and B2B SaaS solutions. Many reach for the option of building a CIAM solution in-house, whilst others look to purchasing 3rd party CIAM vendor SaaS subscriptions or adopting a DIY approach using open-source technology.

Whichever route you take, a modern CIAM implementation relies heavily on several core components that work together to provide a comprehensive identity management solution that includes:

• Authentication
• Authorizing access to resources
• Protecting sensitive customer data
• Managing data privacy and compliance with regulations
• Enhancing user experiences across the various digital touchpoints

My name’s Peter Fernandez, and in my previous article I took a look at what a modern CIAM solution can provide for anyone building a B2C and/or B2B SaaS application.

In this article, I’m going to explore the architecture of a modern CIAM integration, with an emphasis on the core components, technologies, and best practices to create scalable, secure, and customer-centric identity management.

Authentication

Authentication is at the heart of any CIAM implementation, as without it, it’s almost impossible to provide anything else; without authentication, there’s no telling in what context an operation is being performed and hence whether or not that operation is allowed.

Authentication also provides a secure context in which user information (such as user account information and user profile information) can be stored and managed. This information helps provide a seamless and streamlined experience for the user, and handling their data in a safe and regulatory-compliant manner is extremely important.

In a modern CIAM integration, industry-standard best practices and protocols should dictate the approach taken, and various mechanisms have been developed over the years that are proven to provide safety, security and flexibility.

Identity Provider

One such mechanism should be the preferred use of an Identity Provider. An Identity Provider, commonly referred to as an IdP, is typically deployed as an application-independent (centralised) service and is responsible for verifying a customer’s identity when they attempt to access a service.

An IdP will leverage industry standards, such as OIDC and/or SAML, enabling the likes of SSO and determining whether the customer is who they claim to be. Various first-factor authentication methods will typically be supported to provide increased security while maintaining a seamless user experience, including:

• Password-based authentication: The most common method, where users input their username and password.
• Social login: allowing users to authenticate using social media accounts (e.g., Google, Facebook, or LinkedIn).
• Federated login: authentication via a trusted relationship with an organisation’s own central Identity Provider (IdP).
• Passkeys: a discoverable public key cryptographic credential that provides a flexible alternative to passwords across multiple devices.
• Passwordless login: the classic approach of Magic Link (typically via Email) and OTP as an alternative to the password.
• Multi-factor authentication (MFA): adding an extra layer of security by requiring users to verify their identity using additional factors, such as biometrics and/or a one-time password (OTP) sent via SMS or email.

Being application-independent means that authentication scenarios (such as MFA and/or Passkeys, etc.) can be easily enabled/disabled across multiple application platforms (e.g. Browser, Mobile, Desktop et al.) without changing a single line of application code. Moreover, the IdP service can provide proxy capability between IdPs and authentication protocols, which enables connection to the upstream IdPs — crucial for supporting the Social and Federated logins typically associated with B2C and B2B SaaS applications.

Identity Storage

The identity store is the repository for all customer-related data and is typically managed by the IdP implementation deployed. Whilst this is a centralised asset, the store is typically implemented such that account and credential information is maintained separately for an identity. For users, this enables functionality such as Account Linking, and provides secure storage for identity attributes, such as:

• Personal information: Name, email address, phone number, etc.
• Authentication data: Passwords, biometric data, and multi-factor authentication (MFA) secrets.
• Customer preferences: Communication preferences, marketing consent, privacy settings, etc.
• Access rights: Roles and permissions assigned to users.

The identity store must be scalable, secure, and easily accessible. As with the IdP, most modern CIAM systems typically employ cloud-based identity stores that provide high availability and scalability, supporting millions of customer records. Security measures like data encryption (both at rest and in transit) and multi-tier data access controls are typically necessary to protect sensitive customer data.

OIDC

For B2C and B2B SaaS applications, the recommended approach to integrating CIAM Authentication is to leverage an Identity Provider (IdP) using the OIDC (OpenID Connect) Protocol to deliver an ID Token which will be used to validate user authentication — namely Login — and (optionally) build the user session within the application.

In this scenario, each application swaps the direct validation of credentials — typically a UserID and Password, as well as any MFA — for the validation of a token (i.e. an ID Token) generated by the IdP and representing the authenticated state of a user. Of course, if the user does not pass successful authentication, then no token will be generated, which typically signals an unsuccessful authentication or an unauthenticated state.

Authorization

Once a consumer has been authenticated, authorization can be used to determine what resources can be accessed and/or what actions can be taken. This layer enforces access control based on a user’s role, attributes, specific permissions, and or consent.

Delegated Authorization

Using the industry-standard OAuth 2 protocol (see more below) an application-independent Authorization Server can be leveraged to provide the delegated authorization services used to support modern user consent.

In a similar fashion to using an IdP (discussed above), an Authorization Server provides a (centralised) service — in this case, one responsible for verifying consented access to resources and delivering the corresponding security artefact(s) for use. Authorization as a service (as opposed to the Authorization Server itself), can additionally leverage those artefacts for various aspects of Access Control.

An Authorization Server can be deployed as a stand-alone entity and will typically utilize an IdP to perform the necessary precursor authentication required. However, with many of the 3rd party vendor SaaS implementations, such as Auth0 by Okta, the IdP and the Authorization Server are delivered as a combined service, with the pricing strategy typically reflecting this too. Keycloak — a popular open-source solution — is similar but, of course, is free to use, so the combination of functionality does not incur any additional charge. For more on the virtues of the various CIAM integration approaches, see my article entitled Build, Buy or DIY your CIAM Solution?

Access Control

Referring to the control of access to which something or someone is permitted, Access Control is commonly implemented around a number of access control models that can be used in a mix-and-match fashion to create rich access control strategies. Some of the commonly used models for access control include:

• Role-Based Access Control (RBAC): This is one of the most common models used in CIAM, where customers are assigned roles (e.g., “Admin”, “User”, “Guest”), and access to resources is granted based on the assigned role.

• Relationship Based Access Control (ReBAC): A model that can be used to restrict access based on the particular relationships established between one or more users and/or other entities.
• Attribute-Based Access Control (ABAC): Where access is determined by the attributes of the user (e.g., location, subscription status, device type) rather than predefined roles or relationships.

Access control often centres around policies — as in the set of rules that govern who can access certain resources, how they can access them, and under what conditions — and until recently, has been something that a B2C/B2B SaaS solution developer has largely had to manage and implement themselves. However, with the introduction of 3rd party solutions (both vendor-supplied and open-source provided), authorization has become the next up-and-coming phase in the SaaS-provided CIAM space. For more on the subject, read my previous article entitled:

OAuth 2

The recommended approach to integrating CIAM Authorization is to leverage an Authorization Server to primarily provide Delegated Authorization via the delivery of an Access Token using the OAuth 2 Protocol.

The Access Token is used to determine the authorized state, where an API (or other mechanism) via which a Resource Server is accessed can use the token to determine consent, and/or control of access either directly or via a call to some additional service, like OpenFGA. Essentially, the direct validation of credentials to determine authorization is swapped for the validation of the Access Token generated by the Authorization Server, which itself leverages an IdP to determine the authenticated state of a user.

If the user does not pass successful authentication or is not authorized to use a resource, then no token will be generated — which typically signals an unsuccessful authentication or an unauthenticated/unauthorized state.

Management

System Management

Adopting modern standards for Authentication and Authorization typically means adopting a software service approach to CIAM. Implementing an Authorization Server and/or IdP as an application-independent deployment typically means another aspect that needs to be managed. Securely integrating that as part of your existing development toolchain and/or CI/CD workflow(s) largely requires an automated approach.

In a similar fashion, the configuration-as-a-service model adopted by many systems administrators requires mechanisms for performing automated configuration management — particularly in B2B SaaS scenarios where your customers may wish to integrate as part of their existing workflows(s). Whilst a dashboard-style interface is great for ad-hoc administration, securely integrating as part of existing (external) tooling typically requires a less manual approach.

Self-Service Management

Self-service capabilities in a CIAM system enable users to manage their accounts without the need for external assistance. These features enhance the customer experience by offering control and flexibility over their personal information, and include:

• Account registration: Customers can create an account by providing necessary information like their email address, phone number, or Social login details.
• Profile management: Customers can update personal information (e.g., address, contact details), communication preferences, and privacy settings.
• Password reset: Customers can reset their passwords securely via email or SMS without needing to contact customer support.
• Consent management: Customers can manage their preferences regarding the use of personal data, including opting in or out of marketing communications, and reviewing consent for data collection.

These self-service features help reduce friction during user registration and management, ensuring a smoother experience while maintaining security.

Privacy and Compliance

Given the increasing focus on privacy regulations such as GDPR (General Data Protection Regulation), the CCPA (California Consumer Privacy Act), and others, a modern CIAM system must prioritise privacy and regulatory compliance, including features such as:

• Data encryption: Encrypting all personal and sensitive data both at rest and in transit to prevent unauthorized access.
• Audit logging: Maintaining transparent records of all user activities (e.g., login attempts, profile updates, consent management, etc) for security monitoring and regulatory audits.
• Data retention policies: CIAM systems should support policies that dictate how long customer data is retained, in accordance with regulatory requirements. Data should be deleted or anonymised after the retention period has expired.

Compliance features not only ensure adherence to laws but also help organisations build trust with customers by demonstrating a commitment to data privacy.

Protection

Reducing the surface for attack is key to mitigating vulnerability. Protecting CIAM workflows — particularly Login and other user interactivity — from the various efforts of bad actors is key; the consequences of the numerous opportunities for malicious targeting could be catastrophic to your business.

To reduce the surface for any attack, however, you first need to understand the various attack vectors and know when you’re being targeted. Protecting a system is all very well and good, but without effective detection, you could be causing your users needless friction — potentially doing more harm than good.

As detection is key to prevention, the ability to monitor your CIAM integration — either continuously, periodically, or preferably some combination of both — is key to ensuring that your efforts to reduce attacks are working; helping protect your application(s) and safeguarding your users from the likes of:

• Brute-force attack
• Breached Password attack
• Man-in-the-Middle attack
• Suspicious IP attack
• Phishing
• etc.

Best Practices for Implementing a Modern CIAM System

To ensure a successful CIAM integration, B2C and B2B SaaS developers should follow the best practices described above to help ensure security, scalability, and customer satisfaction.

Typically found out-of-the-box with vendors who provide 3rd-party SaaS CIAM solutions, or with DIY CIAM solutions based on open-source technology — though in either case, you’ll typically require some additional integration within your own infrastructure — you’ll need to implement yourself if you go down the bespoke “build it yourself” route:

• Design for scalability: Choose a CIAM solution that can scale to accommodate the growing user base and handle high traffic volumes without compromising performance.
• Prioritize security: Implement robust authentication mechanisms, including multi-factor authentication (MFA), and ensure that all sensitive data is encrypted.
• Simplify the user experience: Minimize friction by offering seamless registration, login, and self-service management, including Social logins and SSO to streamline the authentication process.
• Ensure compliance: Implement strong privacy controls and maintain compliance with relevant data protection regulations (e.g., GDPR, CCPA, etc). Ensure that the system supports consent management and suitable data retention policies.
• Monitor and audit activity: Employ continuous monitoring of user activities and log all access events to detect suspicious behaviour and ensure compliance.
• Leverage extensibility: The ability to seamlessly integrate with various internal and external systems is crucial for scalability and functionality.
• Adopt an API-first approach: An API-first posture, typically protected by the Authorization capabilities of the CIAM implementation itself, will allow you to implement automated command, control and configuration that can scale with business needs and evolving technologies: