CIAM with Auth0 in practice

Workforce IAM serves the people employed by a company: HR or IT creates their accounts, and they sign in to company applications. In CIAM the users are customers and partners who sign themselves up, there are many of them, and they expect fast sign-in to your product.

That is why CIAM is about scale, a smooth sign-up experience and protecting customer data, while workforce IAM is about the account lifecycle and access control for company applications. You cover employees with Okta Workforce Identity and customers with Auth0.

In a B2C model, customers are individuals who sign in to your app as single accounts. In a B2B model, the customer is a company, and its employees sign in as members of that organization, often through their company's SSO.

For B2B, Auth0 offers Organizations. It lets you group users into organizations, such as your customers or partners, give each one its own sign-in methods and assign roles within it. That way you can serve many customers from a single tenant, each with its own sign-in rules.

Signing in with a social account, such as Google or Apple, shortens registration because the user does not create yet another password. Passkeys let people sign in with a fingerprint, a face scan or the device PIN, without a password, and they resist phishing.

It makes sense to enable MFA for customers selectively. Auth0 offers adaptive MFA, which asks for a second factor when sign-in risk is higher, so it does not get in the way of every low-risk login. For sensitive actions after sign-in, use step-up authentication separately.

If you already have your own user database with passwords, Auth0 can take it over in two ways. The first is a bulk import of users with password hashes, but Auth0 accepts only supported hash algorithms, so check yours first; if yours is not on the list, users reset passwords or you migrate them lazily. The second is lazy migration: the user signs in with their existing password, Auth0 checks it against your old database through a script in a database connection and saves the user on its side. The user never has to reset a password, and the migration happens without any action on their part.

The choice depends, among other things, on the hashing algorithm in your current database and on how soon you want to shut down the old system.

You can keep your Auth0 configuration (applications, connections, Actions, roles) as code and change it through review, like the rest of your application. The Terraform provider for Auth0 and the Auth0 Deploy CLI are built for this.

As a result your dev, test and production environments get the right configuration, and every change is visible in the repository history.

Customer data in CIAM is personal data, so it pays to settle roles from the start: usually you are the controller and the CIAM vendor is the processor, with a data processing agreement between you. In practice, four things help: