This article is a brief informal introduction to CIAM. This article is intended to level set a deeper and broader discussion on CIAM which will take place in future blog articles.

CIAM differs in many ways from an organizations IAM systems. A subset of these differences are explained below. These differences are mandated by the different requirements for each system. IAM supports an organizations systems and workforce.

Whereas CIAM supports the organization’s customers or clients. IAM is used to control access to internal systems and data much of which is typically sensitive. Therefore, the users that have Identities in IAM must be more thoroughly vetted and inspected. In addition, the users of the internal IAM system rely on access to perform their job functions therefore the process can have more friction then a customer-based system. This is not to say that customers also do not need to be vetted. Customers often need to be vetted for risk or to prove who their actual identity is. However, with CIAM the goal is to remove as much friction as possible and make user actions be as simple as possible. The reason is that with customers you are usually in a state of either maintaining a relationship or in the customer acquisition phase. And any friction especially in the sign-up process can result in customer’s potentially seeking to do business with someone else. In addition, any complicated actions the user must take has the potential to either make them want to do business elsewhere or will require additional support from you, which is typically costly.

There are many other differences between CIAM and IAM. IAM usually needs to support a limited number of users. Even in a large organization the number of users is going to be in the thousands, tens of thousands, or hundreds of thousands. Where the number of customers can potentially be in the millions, the tens of millions, or more. In addition, a company’s application or website is potentially the main way that the customer interacts with the business. Therefore, ensuring customer satisfaction with their interaction with the application including logging-in is of critical importance. CIAM is also a valuable tool for compliance with customer related laws and regulations such as privacy, whereas IAM systems are important for corporate and industry regulation such as SOX or PCI. In addition, due to the nature of the systems the type of authenticators may be more restrictive with IAM to ensure security while with CIAM there may be more flexibility to meet the customer’s needs such as supporting federation with Facebook or Google for AuthN.

CIAM requirements and capabilities 

At its core CIAM is responsible for assigning a digital identity for a customer. CIAM is responsible for providing a reasonably secure way for that customer to authenticate as this identity. And also, of importance is reducing the likelihood that the customer’s credentials can be compromised and protecting the customer’s identity from impersonation attacks.

Also, as part of the primary security responsibilities of CIAM is to protect the customer’s privacy and data. In banking there are some additional responsibilities that may not either be present in other industries or of less significance. These includes going to great lengths to know your customer to comply with financial regulation. Also, since CIAM gates access to a customers finances it is extremely important to inspect in detail the customers interaction with the company’s systems through CIAM to detect attempts to impersonate the user, fraudulent behavior, and the risk level of the customer or potential customer.

Therefore, in banking CIAM should either handle these activities or securely connect to systems that can. Then depending on the feedback from these systems be able to gate access.

In addition, CIAM is going to perform authentication and potentially maintain state for other resources that may be called when the customer is interacting with the company’s systems. This includes pulling account information from a database, feeding, or receiving information from CRM, notification systems, and any other systems that the user will directly or indirectly come in contact while interacting with the company’s systems.

Then there are customer journeys that are primarily driven through CIAM. These includes tasks such as resetting a password, attaching an authenticator such as a passkey, updating the user’s email, updating the user’s profile, alerting customer of potentially fraudulent behavior taken on their accounts, and letting the customer flag fraudulent behavior. Many of these more identity related tasks should be native to the CIAM, others such as notifications, or updating profiles may require integration with other systems.

In many ways CIAM is the glue that pieces all of the systems that a user may interact with together. Because typically all experiences are essentially going to begin with a login and potentially end with a logout. So, not only should CIAM be fully capable as an Identity Provider but also be intuitive to use and can interact with disparate systems. Friction should be reduced with CIAM systems. Making it simple for the user to create and maintain an identity. Using authenticators that the customer is familiar with whether that be passkeys, or federation with a 3rd party IDP such as Facebook, Google, Microsoft, or Apple. User Identity related actions such as adding passkey, MFA, or resetting a password should be simple and easily understandable to even the most non-technical customer.

Specific requirements 

So, I have spoken in more conceptual way about CIAM. To help you understand actual requirements for CIAM in a more deliberate and detailed way here is a detailed list of common requirements that are often required of CIAM.

•   Centralize authentication, authorization, identity, and credential management for customers
•   Support of modern AuthN and AuthZ protocols including SAML, OIDC, and Auth 2.
•   Ability to perform fraud, risk, and threat analysis or the capability to hand the necessary data to 3rd party systems to perform this analysis and act based on the output of this analysis.
•   The ability to support federation via OpenD or SAML.
•   The ability to work with a variety of 3rd party IDPs including Microsoft, Google, Facebook, and Apple.
•   Support customer journeys either natively or by passing key information to 3rd party apps that can implement the customer journeys.
•   Support of more advanced authentication options including Passkeys, MFA, and passwordless.
•   Ability to acquire, store, and retrieve key profile information that is required for authentication as well as threat, risk, and fraud analysis. This includes information such as keystrokes, mouse movements, page scrolling, email address, phone number, First and Last Name, address, social security number, and any other pertinent information
• Support collection, retrieval, and retention for data used to comply with Know your customer (KYC) regulations
• Ability to store and ask for consent.
• Ability to store and ask for login and other authentication preferences
• Ability to manage and secure PIl
• Support APls wherever possible instead of proprietary code such as SDKs
• Ability to be hosted in AWS
• Ability to support multiple regions and multiple availability zones in AWS or Azure

My next blog posting will be more technical where I will discuss CIAM Architecture.

-Christopher