When To Avoid CIAM
Heya,
I was recently on a podcast, talking about customer identity and access management (CIAM), and the host asked a great question:
When should you avoid CIAM?
So, when should you avoid knowing using customer identity and access management?
I want to answer this question two ways.
No Users == No CIAM
The first is relatively straightforward. Avoid using CIAM systems when you won’t have customers and users.
Customers and users are people accessing a system who are not employees, but are using your systems.
There are a few broad categories of applications that fit this description:
Apps and sites that are entirely anonymous, where the user of the app/site doesn’t have any custom experience/data or they’re all kept locally. This could be a brochure site (where there really are no users) or an anonymous userbase, where there is no user identity tracked by the central server.
Data processing applications, where there really are no users. This might be an app that pulls from one datastore, transforms or reifies data, and pushes it elsewhere. No users, no need for CIAM.
An internal application which has users, but can leverage an internal directory or IAM system. In this case, CIAM doesn’t make sense, because the app is internal and there’s already a ready made user store for controlling access. Don’t re-invent the wheel.
When Should You Avoid A CIAM System?
The second way to look at this is when to introduce a standalone CIAM architectural component.
That is to say, when do you introduce a system which normalizes your user data.
When you have a single SaaS application which has user data in the same database as the application data, you have CIAM; it’s just bundled in.
When you have one application, bundled CIAM makes sense. It is simpler to reason about, simpler to change, and simpler to deploy user data models when they are entangled with your application code. However, there are reasons to use a standalone system even then.
But as soon as you have more than one system that your users are going to access, then centralizing that user data is a good idea. This may happen sooner than you think.
Even early stage SaaS applications can have:
the central, custom built app
user support forums or chat systems
paid user support channels
user feedback systems
There are plenty of options out there that treat the above as user data silos. I once worked for a startup which used Facebook Groups as a support forum and plenty of folks start out with email as the sole means of paid support.
But if you can get a central view of all your users, you’ll be surprised at the benefits.
Dan