CIAM vs. IAM: The key differences 'customer' makes
Find out everything you need to know about the nuances that differentiate customer IAM from traditional IAM so that you can implement the CIAM system at your organization.
What's good for your employees isn't always good for your customers. That probably goes without saying, right? After all, you'd never ask customers to sign and acknowledge the employee handbook -- or invite them into the office football pool.
This fundamental truism may seem painfully obvious, but understanding it is the core of comparing CIAM vs. IAM. Meaning, because customers have different needs, expectations and motivations from employees in how, when and why they interact with your organization, so too do the systems supporting customer access have different goals and requirements.
That's also not exactly rocket science, but it's important that practitioners understand the nuances here. This is particularly true when evaluating customer IAM or IAM tools, because the requirements, feature sets and evaluation criteria can be different from what security practitioners might expect.
With this in mind, let's explore what CIAM is all about: how it differs from traditional IAM and the features that make it useful.
CIAM vs. IAM
Most practitioners already know that IAM is the discipline of ensuring that authorized individuals are given access to the right resources at the right time. While identity management considerations generally extend to both customers and non-customers -- e.g., employees, temporary staff, contractors and the like -- as a practical matter, the lion's share of IAM systems organizations deployed over the years have focused on one primary user population: employees. IAM systems are used to streamline user provisioning (both for on-premises applications and cloud-based ones), manage access rights, assist in compliance reporting, automate approval workflows, fuel authentication and authorization, and for numerous other security-relevant functions. As organizations look to streamline and expand the services that they offer, though, they're finding that they have a need to do these same things in equal measure for customers.
Historically, organizations often lay the issue of customer identity at the feet of developers authoring the applications customers will use -- and at a relatively modest scale. An application of yesteryear, for example, might be accessed by a customer entirely from one device. It might use a proprietary identity assigned to the customer at registration (stored, for example, in an application-specific user table in a database), maintain a relatively modest population of users, and employ access control and authentication measures built into the application itself.
CIAM is all about servicing these modern customer requirements in a way that's reusable and extensible.
Modern applications need more because customers demand more. Customers demand minimal hassle. Where possible, they expect to be able to use multiple services and applications within an organization's ecosystem seamlessly, without having to re-authenticate. Other expectations include an experience that is portable across multiple devices -- everything from customers’ phones or tablets to their televisions and automobiles -- and in many cases preserving a session from device to device. High performance and rapid response at any time of day or night is essential. If you don't provide these things but your competitor does, where do you think customers will go?
CIAM, therefore, is all about servicing these modern customer requirements in a way that's reusable and extensible. The systems that support and enable these requirements are, in a nutshell, what CIAM is all about.
CIAM vs. IAM: Features, differentiators
So what differentiates CIAM vs. IAM from a feature perspective? There are a few key differences, but perhaps the most significant one from an architectural standpoint is scalability. A CIAM needs to scale in ways that would have been unthinkable just a few years ago -- to potentially millions or tens of millions of user records at a level of throughput that's higher than you might expect. Consider, for example, a service like LinkedIn -- you'd expect consistent customer login throughout the day, but what about Monday between 8 a.m. and 9 a.m.? What about for an electronic greeting-card platform during a major holiday? Not only do CIAM systems need to handle these spikes, but they need to do so seamlessly with no observable degradation in response time. This level of scalability, if not architected in from the outset, can be very challenging to bolt on after the fact.
Additionally, CIAM needs to support fast and flexible customer authentication to multiple applications from multiple devices. It needs to be able to access potentially dozens of modular and "componentized" applications (potentially spanning multiple environments at cloud providers or on premises), with seamless login to services and applications provided by others -- like outsourced customer support portals or real-time sales or customer support chat interfaces. This needs to be done seamlessly without exposing the "plumbing" of how this works to customers -- or, worse yet, requiring an additional login. And, as mentioned above, authentication state needs to be preserved over devices (some CIAM vendors call this omnichannel). This means, if a customer is in the middle of a chat with a sales or customer-support rep on their computer, they need to be able to switch to another device -- like their phone -- without restarting the entire session from scratch or re-authenticating.
Customer IAM also needs to target flexibility as part of the core feature set so that, as you grow, the system can accommodate new uses. For example, maybe today you have just one or two user types -- maybe administrators and regular users. Tomorrow, though, you could have multiple service levels: regular, gold and platinum subscribers, for example. Information about who the customer is allows future personalization of experience to them as well as tracking of their membership status, which in turn can govern authorization to certain features or, in some cases, requirements for enhanced authentication.
What's clear in a CIAM vs. IAM comparison is that customer IAM must provide one shared, accessible, highly available and (ideally) "future-proofed" location where you can store information about customers. Depending on use case and intended goals, this might be a directory like you'd employ for internal users, or it might be an alternative mechanism. Either way, because of the additional requirements for customers and the differing levels of scale involved, vendors have begun to specialize the products they offer to target the customer identity space specifically. That's not to say that you can't employ a traditional IAM tool to help in this regard (some of those products claim to allow extension of functionality to customers as well), but very often the shift in focus and new requirements means looking for a different or expanded tool set to realize those goals.
