CIAM vs IAM: What's the Difference?

The term ‘identity and access management’ (IAM) is often used when software is discussed. You may also have heard the term ‘CIAM’, to mean ‘customer IAM’ or ‘consumer IAM‘. These terms can feel confusing to companies building digital services, and when and where you should use them may not be clear.

This article explains IAM v CIAM in terms of business requirements. Differences between workforce identities and customer identities are first explained. Next, common security requirements and behaviors are described, that organizations will need for their digital solutions. Finally, the article will show how different identity components can work together.

IAM Workforce Security

Employees at most companies use one or more cloud platforms, and their Software as a Service (SaaS) features. DevOps and Engineering often make heavy use of a cloud platform to deliver their applications. Sales and Marketing may use a different, more specialist platform, perhaps for customer relationship management (CRM). All departments will typically use shared services, such as email and cloud documents.

These platforms provide an Identity Provider (IDP), where you can register each employee, and assign them credentials. You will typically also assign employees to groups, then set resource permissions to each group. Employees can then use the features of the third party platform securely.

Building Digital Solutions

The organization will also build its own digital products, for its internet customers. This might involve multiple web and mobile apps, as well as providing B2B APIs to partners. A modern architecture may involve the following moving parts, all of which need to be secured, without slowing down your business deliverables.

Security is now targeted at your customers, and requirements will be deeper than in workforce scenarios. What makes business software difficult to build, is that there is never a one size fits all solution, even within each business sector. Instead you will design multiple security solutions based on business use cases. It can also be common for requirements to vary across products.

Firstly, consider customer registration and the login user experience. Whereas it might be fine for employees to sign in via a cloud provider such as Microsoft, it is unlikely that you will want customers to login to your business apps in the same way. Instead you are likely to require branding per application, and to be able to support multiple forms of authentication.

There are also many subtleties around protecting data in APIs. You will need a secure design for calling APIs, and to follow security best practices for each type of client. The main data protection then involves enforcing your business rules, which may involve authorizing based on owned resources, subscription levels or which partner is calling a microservice.

The OAuth Framework

These days, most security implementations use the OAuth family of specifications, which enables you to meet your security use cases. The key component in OAuth is the authorization server, introduced in RFC6749. It provides the CIAM role and implements security standards that have been vetted by many experts.

When applied correctly this enables end-to-end solutions with the simplest code and fewest vulnerabilities. Applications and microservices no longer need to implement difficult security. Instead they send lightweight messages to the CIAM system, receive tokens, and verify them according to JWT best practices.

The CIAM system should continually improve its support for security standards, or ‘flows’. The OpenID Connect code flow is the best known of these, and provides the most powerful options for controlling authentication behavior from web and mobile clients. Newer standards are also frequently released, a recent example being the CIBA flow. This can be used to enable a call center operative to securely act on behalf of a remote user. Following standards will make your implementations easier, keep your apps secure, and avoid complex code.

The other key behavior you will need is extensibility. It may be possible to integrate your applications directly with a workforce identity provider. Usually though, these are not designed to provide all of the ingredients you will need to secure your digital services. Meaning that eventually you will run into problems due to insufficient extensibility. This can result in security compromises, blocking issues, or complex workarounds.

Identifying CIAM Requirements

Since registration and login will be the first experiences consumers have of your digital solutions, you want these flows to feel like part of your apps. A workforce IAM system will enable some basic customization, such as using your company logo and basic styling. A CIAM system should instead allow you to take complete control over the look and feel per client.

Next, you must be able to design authentication workflows according to your needs. Start by reviewing the authentication methods supported, but also look beyond this. Verify that the CIAM system supports custom behavior, such as the ability to involve your business data in authentication decisions. Ensure also that you can use account linking to safely migrate users to newer authentication methods such as passwordless.

Another key area is how you protect data in your microservices. This should follow a zero trust architecture, so that every request for secured resources undergoes authentication and authorization. Two important requirements here are the use of opaque tokens, to prevent information disclosure, and the ability to issue claims from your business data to OAuth tokens:

Enabling Employee Access

Your workforce IAM systems remain highly useful for authenticating employees, and managing their credentials. The main work credentials used by your staff are often stored in a cloud system. You can enable employees to use this credential to sign into your digital products. This is done by configuring the workforce IAM system in the identity provider role, and does not require any code changes to your applications:

This type of setup gives you the best of all worlds, where employees and customers can authenticate in different ways. For both customer and employee usage, your microservices use tokens issued by the CIAM system. You have full control over claims issued, token lifetimes and other security properties.

The Curity CIAM Solution

At Curity we provide a Customer IAM product with support for many standards and security features. A key design principle is ‘separation of concerns’, to provide building blocks that companies need. All important behaviors are represented as abstractions. Basic extensibility is managed via configuration or simple Javascript, or you can provide bespoke implementations via plugins. This enables you to extend all of the important behaviors when building your security solutions.

Security design can also be difficult for companies. We therefore also provide extensive identity and access management resources for engineering teams. This includes recommendations on the most effective patterns, to remove uncertainty. See our single page application (SPA) and zero trust API designs for examples. All of this provides you with the best security for your digital solutions, while also enabling employee access via workforce IAM.