Customers should get through login on the first try. Attackers shouldn't.
Abandoned sign-ups and credential-stuffing spikes hit the same login page, so fraud controls can't get in a customer's way. We build customer identity on Auth0 and Microsoft Entra External ID. We move users off Azure AD B2C or homegrown login code, and send clean profile and consent data to Salesforce or Dynamics 365.
CIAM tenantAuth0 · Entra External IDActions and extensionsrisk checks · profile enrichmentLegacy user storeAzure AD B2C · custom login
03 · Business systems
Your APIsvalidate access tokensCRMSalesforce · Dynamics 365Consent recordsmarketing · privacy
Auth0Microsoft Entra IDOktaSalesforce
in short·15-second read
Customer identity and access management (CIAM) covers sign-up, login, account recovery and consent for the people who use your products, rather than your employees.
We design and build CIAM on Auth0 (which Okta also sells as Customer Identity Cloud) and on Microsoft Entra External ID. We also plan migrations off Azure AD B2C and custom login code, add passkeys and connect customer profiles to your CRM.
you probably need this if
Sign-up abandonment is high and the login page is one of the suspects.
Credential-stuffing spikes hit your login page and lock out real customers.
You run Azure AD B2C with custom policies and need a plan for External ID.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Customer Identity, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · customer identity3 open
openSign-up abandonment is high and the login page is one of the suspects.
recurringCredential-stuffing spikes hit your login page and lock out real customers.
blockedYou run Azure AD B2C with custom policies and need a plan for External ID.
exposure
Auth0 tenant and Actions designAzure AD B2C to External ID…Passkeys and passwordless for…B2B and partner loginMigration from custom login codeProfile, consent and CRM sync
startrehearsehandover
Map the flows
Design
Build and migrate
Tune after launch
we are here
ready to hand over
The Rules are gone.
The team knows which paths move as configuration and which need code, has a working…
New enterprise customers set up their own SSO now.
Map of current and target customer sign-in flows
chapter 01 · where it hurts
Why teams reach out
Sign-up abandonment is high and the login page is one of the suspects.
Credential-stuffing spikes hit your login page and lock out real customers.
You run Azure AD B2C with custom policies and need a plan for External ID.
chapter 02 · what we change
How we solve it
Auth0 tenant and Actions design
Azure AD B2C to External ID migration
Passkeys and passwordless for consumers
B2B and partner login
Migration from custom login code
Profile, consent and CRM sync
chapter 03 · how it runs
Our approach
Map the flows
Design
Build and migrate
Tune after launch
chapter 04 · where you end up
What changes
The Rules are gone.
The team knows which paths move as configuration and which need code, has a working prototype of the hardest one, and has a migration plan that doesn't depend on the original authors.
New enterprise customers set up their own SSO now.
Map of current and target customer sign-in flows
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Each environment gets its own tenant. Actions handle profile enrichment and risk checks, and login configuration deploys from source control, so a change to the sign-in flow gets code review like any other release.
Microsoft stopped selling Azure AD B2C to new customers on 1 May 2025, and new features now ship only in External ID. We go through your custom policies one by one, rebuild each sign-in flow as user flows and custom authentication extensions, and move users across without forced password resets wherever we can.
Passkey enrollment offered at moments people say yes, such as right after a successful login or checkout, with an email or phone fallback that doesn't reopen the door to account takeover.
Each business customer becomes an organization with its own IdP federation, and its admins manage their own users without filing tickets with you.
If the old hashes use an algorithm the new platform supports, we import them in bulk. If they don't, lazy migration moves each user the next time they log in. Either way customers keep their passwords, and the old user table can be retired.
One customer identifier shared by the identity platform and Salesforce or Dynamics 365, with consent records that marketing and privacy teams both trust.
capability 01 / 06in production
Auth0 tenant and Actions design
Each environment gets its own tenant. Actions handle profile enrichment and risk checks, and login configuration deploys from source control, so a change to the sign-in flow gets code review like any other release.
Microsoft stopped selling Azure AD B2C to new customers on 1 May 2025, and new features now ship only in External ID. We go through your custom policies one by one, rebuild each sign-in flow as user flows and custom authentication extensions, and move users across without forced password resets wherever we can.
Passkey enrollment offered at moments people say yes, such as right after a successful login or checkout, with an email or phone fallback that doesn't reopen the door to account takeover.
If the old hashes use an algorithm the new platform supports, we import them in bulk. If they don't, lazy migration moves each user the next time they log in. Either way customers keep their passwords, and the old user table can be retired.
One customer identifier shared by the identity platform and Salesforce or Dynamics 365, with consent records that marketing and privacy teams both trust.
We pieced these together from Customer Identity situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Auth0 Rules still running login logic weeks before end of life
composite · not a client story
Beforethe situation
Twelve or so Rules run in an Auth0 tenant, adding roles to tokens, calling a fraud API and linking accounts by email. Rules and Hooks reach end of life on 18 November 2026. The login flow has no automated tests.
What we dothe work
Export the tenant with the Deploy CLI and map each Rule to a post-login Action. Write tests for every token claim a downstream API reads, compare tokens from Rules and Actions in a development tenant, then cut over per application with the old Rules disabled first and deleted later.
Afterwhere you end up
The Rules are gone. Login logic lives in versioned Actions with tests, every API sees the claims it saw before, and the end-of-life date comes and goes without a login incident.
case file 02
Azure AD B2C custom policies with an identity verification step
composite · not a client story
Beforethe situation
A B2C tenant runs Identity Experience Framework custom policies, including a REST technical profile that calls an ID verification vendor during sign-up and a separate sign-in flow for a partner portal. The people who wrote the XML have moved on.
What we dothe work
Read every policy file and diagram each sign-in path. Decide which paths map to External ID user flows and which need custom authentication extensions. Prototype the verification step first, since it carries the most risk, and choose a password strategy per hash format.
Afterwhere you end up
The team knows which paths move as configuration and which need code, has a working prototype of the hardest one, and has a migration plan that doesn't depend on the original authors.
case file 03
Enterprise customers who want SSO from their own Okta or Entra tenant
composite · not a client story
Beforethe situation
The product is B2B SaaS, and the enterprise customers want staff to sign in through their own IdP. Every new SAML connection is a support ticket. An engineer configures each one by hand.
What we dothe work
Model each business customer as an Auth0 Organization with its own connection, give customer admins a guided setup flow, and map their IdP groups to product roles in one Action. Move the existing hand-built connections over one customer at a time.
Afterwhere you end up
New enterprise customers set up their own SSO now. Roles land in the token the same way for every customer, and support has stopped editing SAML settings by hand.
Where customer identity sits between your apps and your CRM
Web, mobile and partner logins all run through one CIAM tenant, which calls Actions for risk checks and migrates legacy users as they sign in. Your APIs receive access tokens, and profile and consent data sync to the CRM.
01 · Customer channels
Web apphosted login page → CIAM tenant · OIDC login
Legacy user storeAzure AD B2C · custom login → CIAM tenant · lazy migration
03 · Business systems
Your APIsvalidate access tokens
CRMSalesforce · Dynamics 365
Consent recordsmarketing · privacy
Read the diagram as text
Web app → CIAM tenant: OIDC login
Mobile app → CIAM tenant: PKCE auth code
Business customer IdP → CIAM tenant: federation
Actions and extensions → CIAM tenant: login hooks
Legacy user store → CIAM tenant: lazy migration
CIAM tenant → Your APIs: access token
CIAM tenant → CRM: profile sync
CIAM tenant → Consent records: consent
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Map the flows
Every sign-up, login, recovery and profile flow across web and mobile, with drop-off and support-ticket data where you have it.
step 02
Design
Tenant topology, identity providers, MFA and passkey policy, and the customer data model shared with CRM.
step 03
Build and migrate
We build flows in lower environments first. Users then migrate in cohorts, with the old and new login running side by side until the last group is over.
step 04
Tune after launch
Bot and fraud signals, conversion rates and support tickets reviewed weekly at first, and policies adjusted to match.
you keep
What you're left with
We write these for your Customer Identity setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Customer Identity (CIAM) work. The ones who've done it answer differently from the ones who've read about it.
Q1
What happens to users whose password hashes we can't export or the new platform can't import?
Custom or peppered hashes often can't be verified elsewhere. Lazy migration keeps the old system online during the transition, so ask how long that lasts and who keeps it patched.
Q2
How will you model our monthly active user costs against real login patterns?
CIAM pricing depends on MAUs and add-ons such as SMS MFA and bot protection. Seasonal peaks and leftover test accounts can push you into a tier nobody budgeted for.
Q3
Which identifier links a CIAM user to a CRM contact, and which system owns it?
Matching on email breaks when customers change address or share one. A stable identifier owned by one system prevents duplicate contacts and orphaned consent records.
Q4
How will login changes be tested before a release reaches customers?
A broken login costs revenue faster than most bugs. Expect automated tests per flow and per token claim, run in a separate tenant, with configuration deployed from source control.
Q5
How will you deal with credential-stuffing spikes without locking our real customers out?
Account lockout punishes the customer more than the attacker. Look for bot detection, breached-password checks and rate limits tuned against your own traffic.
01We're on Azure AD B2C. Do we have to move now?
No. Microsoft says it will support Azure AD B2C until at least May 2030, and existing customers can still create tenants and user flows. New capabilities go to External ID only, though, so the real question is when you move. Tenants with heavy custom policies take longest. Start that inventory early.
02What drives the cost of a CIAM platform?
Monthly active users, the add-ons you need (SMS MFA, bot protection, B2B features) and how many tenants and environments you run. External ID's core offer is free for the first 50,000 monthly active users, and its add-ons are billed separately. We model the candidates against your real login volumes before you sign anything.
03Is Okta Customer Identity Cloud the same product as Auth0?
Yes, same product. Okta calls Customer Identity Cloud "powered by Auth0", and the APIs, SDKs and URLs still say Auth0. Contracts and documentation will use both names.
04Can customers keep their passwords when we migrate?
Usually. If your current system stores password hashes in an algorithm the new platform can import, we bring them over in bulk. If not, lazy migration checks the password against the old system on first login and moves that user then.
05Do you build the login screens too?
Yes. We can brand the hosted login page, which is the safer default, or build native login screens inside your mobile app when the product team needs full control and accepts the extra security work that comes with it.
related
Often paired with
Projects on Customer Identity (CIAM) usually end up touching one of these, so they're worth a look.
