Homegrown customer login to Auth0 or Okta Customer Identity
Cohash replaces homegrown customer login with Auth0, Okta's customer identity platform. We read the current user store and how passwords are hashed, then set up development, staging and production tenants with Universal Login. Users move by bulk import or by automatic migration when they next sign in. Passkeys and MFA go in, and post-login Actions keep Salesforce or Dynamics 365 contact records current.
- 01Read the current user store
- 02Tenants and Universal Login
- 03Move users
- 04Connect apps and CRM
- 05Cut over and retire the table
The story
Told without the client's name or anything that could identify them.
A subscription business's digital team ran customer sign-in on homegrown code, with passwords in an application table hashed by a scheme chosen years earlier. Reset, MFA and lockout were custom code that rarely got tested, and bot sign-ups and credential stuffing showed up in the logs every week. We started by reading the user store: hash format, duplicate emails, unverified accounts and every app that read the table. Users then moved to Auth0 through bulk import or automatic migration on next sign-in, the apps switched to Universal Login over OIDC, and the old password columns were dropped once migration traffic fell away.
why it was urgentIn July 2025 NIST published SP 800-63B-4, now the federal baseline for authenticators and password rules. On 21 May 2026 Auth0 made Auth for MCP generally available, which lets your customers' AI agents call your APIs with proper OAuth. Getting a homegrown login table to support either one is real engineering work.
- openYour customers' passwords still live in an app table, hashed however somebody decided to hash them years ago.
- recurringPassword reset, MFA and account lockout are custom code that rarely gets tested.
- blockedBot sign-ups and credential stuffing show up in the logs every week.
- openBusiness customers ask to sign in with their own Okta or Entra ID.
The estate, before and after
Before: homegrown sign-in in front of an application user table
Web and mobile apps posted credentials to custom login code that checked an old hashing scheme in the app's own table. Reset, MFA and lockout were custom code, and bots hit the same form as customers.
After: Auth0 Universal Login handles every customer sign-in
Apps hand sign-in to Auth0 over OIDC with PKCE. Users who haven't moved yet migrate on next login through a custom database connection. Post-login Actions keep CRM contacts current, and business customers federate their own identity provider.
How we run it, phase by phase.
5 phases take you from Homegrown customer login and user table to Auth0 customer identity. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Read the current user store
We record the hash algorithm, salts, duplicate emails, unverified accounts, profile fields and every app that reads the user table. That's what decides between bulk import and automatic migration.
- phase 02
Tenants and Universal Login
We set up development, staging and production tenants with a custom domain, Universal Login branding, and passkey, MFA and attack protection settings. Tenant configuration is exported to source control with the Deploy CLI.
- phase 03
Move users
We bulk import users whose hash format is supported. Everyone else moves when they next sign in, using a custom database connection with automatic migration, tested first against a copy of the user store.
- phase 04
Connect apps and CRM
The web and mobile apps move to OIDC with PKCE. We use post-login Actions to update Salesforce or Dynamics 365 contacts, and Organizations for business customers who want to sign in with their own identity provider.
- phase 05
Cut over and retire the table
We shift traffic to Universal Login a slice at a time and watch the tenant logs as it goes. Once migration traffic tails off, the old login code and the password columns come out.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Customers kept their passwords through the move
We bulk imported every user with a supported hash and migrated the rest when they next signed in, through a custom database connection. Nobody got a forced reset email.
- result 02
Sign-in runs on Universal Login with passkeys and MFA
Passkeys, MFA and attack protection used to be custom code. Now they're tenant settings, and they apply to web and mobile alike.
- result 03
CRM contacts stay current from sign-in
Each sign-in now runs a post-login Action that updates the customer's Salesforce or Dynamics 365 contact record.
- result 04
Business customers bring their own identity provider
We set up Organizations so business customers sign in with their own Okta or Entra ID and skip a separate password.
- result 05
Tenant configuration lives in source control
We export the development, staging and production tenants with the Deploy CLI, so a change gets reviewed and promoted the same way code does.
Risks we plan for
-
Duplicate accounts by email
It's common to find the same email in a homegrown store twice, with two different passwords. We settle account linking rules before the import, otherwise those users get two profiles.
-
Monthly active user costs
What you pay for Auth0 depends on active users and features. Test accounts, bots and dormant users inflate the count, so we find them before you pick a plan.
-
Mobile apps on old versions
Users who never update the app keep calling the old login endpoint. It stays up, or forces an upgrade, until usage falls.
-
Session cut-over
Sessions don't carry over to Auth0. So we pick when to switch and let users know ahead of time, to avoid logging anyone out in the middle of a checkout.
Where AI helps, and where it needs guardrails
Auth0 for AI Agents adds Token Vault and asynchronous authorization for approvals. It also adds fine-grained authorization, so retrieval only returns what a user may see. And Auth for MCP lets your own MCP servers accept OAuth tokens. If customers or their agents will reach your services through MCP, put the scopes and consent screens into this build. API keys added later are what we're trying to avoid.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- report01
User store analysis covering hashes, duplicates and dependent apps
yours to keep - evidence02
Tenant configuration in source control for three environments
yours to keep - tests03
User migration plan with bulk import and automatic migration tested
yours to keep - document04
Post-login Actions for CRM sync and enrichment
yours to keep - runbook05
Cut-over runbook and attack protection settings
yours to keep
Platforms and services on this move
Services involved
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01custom database connection
- An Auth0 connection that hands login checks to scripts you write, and those scripts talk to a database you already run. It's what keeps the old user table working while you move.in context →
- 02Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 03Actions
- The replacement for both. Each one is a small JavaScript function you attach to a trigger such as post-login. It carries its own secrets, and other Actions can't read them.in context →
- 04tenant logs
- Auth0's running record of logins, errors and other events in your account. How far back you can look depends on your plan, and it can be as little as a day.in context →
- 05tenant
- Your company's Microsoft account. Every environment draws on one shared pool of storage, so a bloated test copy hits everyone.in context →
- 06passkey
- A sign-in key that lives on your phone or computer, or on a security key you carry. You never type a code, so a fake login page has nothing to steal.in context →
Certified engineers, wherever you need them.
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.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Will customers have to reset their passwords?
Not if we can import the hashes or use automatic migration. With automatic migration the user signs in once with their old password, Auth0 checks it against your database, and stores it from then on.
02Auth0 or Okta Workforce Identity for customers?
They're different products. Auth0 is Okta's customer identity platform, with Universal Login, Organizations for business customers and MAU-based pricing. Workforce Identity is built for employees. Customer sign-in, we put on Auth0.
03What drives the cost?
Monthly active users, which features you need, how many apps connect, and how messy the existing user data is. We count active users from your logs before you choose a plan.
04Can you also handle our B2B customers?
Yes, that's what Organizations is for. Each business customer connects its own Okta, Entra ID or SAML identity provider and manages its own users.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case study6bc242d3 - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it