Architecting a CIAM Solution

Reading Time: 11 minutes

There are numerous use case scenarios that occur within a typical B2C or B2B SaaS solution: from user interactions via the front-end (browser) for SPAs and classic Web Applications to the native interfaces provided by Mobile and Desktop Apps — each connecting with the participation of Backends, BFFs, APIs and Services. Managing customer identities and ensuring secure access in such scenarios has become a key challenge for organisations developing B2C and B2B SaaS solutions, particularly where those identities can originate from multiple sources, too (e.g via Social or Federation). 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 architecture relies heavily on several core components that work together to provide a comprehensive identity management solution, each contributing to the overall safety and security whilst enhancing user experiences across the various digital touchpoints:

• Authentication
• Authorising access to resources
• Protecting sensitive customer data
• Managing data privacy and compliance with regulations

In my previous article, entitled What Can CIAM Do For You, I took a look at what a modern CIAM solution can provide for anyone building a B2C and/or B2B SaaS application. My name’s Peter Fernandez, and in this article, I’m going to explore the architecture of modern CIAM, with an emphasis on the core components, technologies, and best practices to create scalable, secure, and customer-centric identity management that:

• Embraces scalability: Provide a solution that can scale to accommodate growing user bases and handle high traffic volumes without compromising performance.
• Prioritises security: Implement robust authentication mechanisms, including multi-factor authentication (MFA), to ensure that all sensitive data is cryptographically secured.
• Simplifies the user experience: Minimise friction by offering seamless registration, login, and self-service management, including Social logins and SSO to streamline the authentication process.
• Ensures compliance: Implement strong privacy controls and maintain compliance with relevant data protection regulations (e.g., GDPR, CCPA, etc), supporting consent management and suitable data retention policies.
• Monitors and audits activity: Employ continuous monitoring of user activities and log all access events to detect suspicious behaviour and ensure compliance.
• Leverages extensibility: Enables seamless integration with various internal and external systems, crucial for scalability and functionality.
• Adopts an API-first approach: An API-first posture, typically protected by the Authorization capabilities of the CIAM implementation itself, that allows you to leverage automated command, control and configuration, which can scale with business needs and evolving technologies.

Authentication

Authentication lies 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, where handling their data in a safe and regulatory-compliant manner is extremely important.

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 when integrating a modern CIAM solution.

Identity Provider

The preferred mechanism of choice when it comes to Authentication should be the 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; you can my companion article, B2C and B2B SaaS Authentication Architectures, to discover more about the value using your own IdP can provided.

An IdP will leverage industry standards, such as OIDC (more below) 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 front-line security while maintaining a seamless user experience, including:

• Password-based authentication: arguably, still the most common method, where users input their username and password.
• Social login: allowing users to authenticate using the so-called social accounts (e.g., Google, Facebook, or LinkedIn).
• Federated login: authentication via a trusted relationship with an organisation’s own central Identity Provider (IdP).
• Passwordless login: the classic approach of Magic Link (typically via Email) and OTP as an alternative to the password.
• Passkeys: a discoverable public key cryptographic credential that provides a flexible, modern passwordless alternative across multiple devices.
• Multi-factor authentication (MFA): adding an extra layer of security 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, etc.) 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 also a centralised asset, the store is typically implemented such that account and credential information is maintained separately for any given identity. For users, this enables functionality such as Account Linking — a pivotal aspect of SSO — and provides secure storage for identity attributes, such as:

• Personal information: Name, email address, phone number, etc.
• Customer preferences: Communication preferences, marketing consent, privacy settings, etc.
• Authentication data: Passwords, public passkey data, and multi-factor authentication (MFA) secrets.

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 the OIDC (OpenID Connect) Protocol to deliver an ID Token that 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 the 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 will typically signal 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. Authorization enforces access based on a user’s role, attributes, specific permissions, and/or consent. Authorization data is used to both inform the user interface (e.g. enabling or disabling functionality based on capability) and restrict a user based on what they are allowed or not allowed to do. Again, 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 when integrating a modern CIAM solution (see the article entitled OIDC, SAML and OAuth2.0 for more).

Authorization Server

In a similar fashion to an IdP (discussed above), an Authorization Server provides a centralised application-independent service — in this case, one responsible for verifying access to resources. An Authorization Server can be deployed as a stand-alone entity and will typically utilise 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 approaches, see my article entitled Build, Buy or DIY your CIAM Solution?

Consent

Using the industry-standard OAuth 2 protocol (more below), an application-independent Authorization Server can be leveraged to provide the Delegated Authorization services used to support modern user consent. Consent allows a user to explicitly grant a (third-party) client — i.e. an application — access to protected resources held by a resource server, enabling the client to act on the user’s behalf without the user needing to reveal their credentials.

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 via Authorization Code Flow to deliver an Access Token in the context of a consenting user, created by using the OAuth 2 Protocol. An Access Token — also known as a Bearer Token when delivered via an HTTP header — is comparable to an API Key, but where context, lifetime, and auditability can be assured.

The Access Token is used to determine authorised state — where an API (or other mechanism), via which a resource is accessed, can use it to determine consent, and/or the control of access either directly or via a call to some additional service, like OpenFGA. The validation of the Access Token (otherwise referred to as the Bearer Token) generated by the Authorization Server and leveraging authentication via an IdP is used to determine the authorised state of a user.

Again, if a user does not pass successful authentication or is not authorised to use a resource, then no token will be generated, typically signalling an unsuccessful authentication or an unauthenticated/unauthorised state. The use of an Access Token provides significant advantages over the use of an API Key, and I’ll be discussing this more in a future article.

Management

The ability to manage a CIAM implementation in a centralised manner largely goes without saying: the dashboard-like interface provided by most implementations, both from third-party SaaS vendors and via an open-source DIY approach, is commonplace. However, what can often be overlooked is the value and the richness of functionality indicative of also supporting the API-first approach.

System Management

Adopting modern standards for Authentication and Authorization typically means adopting a service-oriented approach to CIAM. Implementing an Authorization Server and/or IdP as an application-independent deployment typically means another aspect that needs to be managed, and 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 implementation 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, help reduce friction during user registration and management, ensuring a smoother experience while maintaining security, and generally include:

• Account registration: Customers can create an account by providing necessary information like their email address, phone number, or Social login details.
• Password reset: Customers can reset their passwords securely via email or SMS without needing to contact customer support.
• Profile management: Customers can securely update personal information (e.g., address, contact details), communication preferences, and privacy settings.
• 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.

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 solution must prioritise privacy and regulatory compliance, with features for the latter not only ensuring adherence to laws but also help organisations build trust with customers by demonstrating a commitment to data privacy:

• Data encryption: Encrypting all personal and sensitive data both at rest and in transit to prevent unauthorised 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.

Brand Management

Particularly pertinent for B2B, the ability for organisations to leverage their own branding — ideally in a self-service fashion — offers customisation that’s typically expected by SaaS (corporate) customers. This becomes even more relevant for B2B2C and B2B2B (the Business-to-Business-to-Consumer/Business scenarios involving the repackaging of SaaS solutions), where brand recognition is even more important.

Protection

Reducing the surface for attack is key to mitigating vulnerability. CIAM workflows, particularly Login and other user interactivity, that detect and protect against the various efforts of bad actors are crucial: the consequences of the numerous opportunities for malicious targeting could be catastrophic to your business. As detection is key to prevention, the ability to enable progressive monitoring within a CIAM implementation — either continuously, periodically, or preferably some combination of both — is key to ensuring that your efforts to reduce attacks are working.

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 if you don’t know what you’re protecting against, your protection mechanisms could be causing users needless friction, potentially doing more harm than good. An understanding of the various attack vectors is therefore fundamental, helping to 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.