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.
Read the diagram as text
- Customers → Web app: password sign-in
- Customers → Mobile app: password sign-in
- Bots and credential stuffing → Web app: stuffing attempts
- Web app → Homegrown login code: form post
- Mobile app → Homegrown login code: legacy endpoint
- Homegrown login code → User table: hash check
- User table → Salesforce or Dynamics 365: contact data
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.
Read the diagram as text
- Customers → Web app: sign in
- Customers → Mobile app: sign in
- Business customers → Web app: sign in
- Web app → Auth0 Universal Login: OIDC + PKCE
- Mobile app → Auth0 Universal Login: OIDC + PKCE
- Auth0 Universal Login → Custom database connection: migrate on login
- Auth0 Universal Login → Post-login Actions: post-login
- Post-login Actions → Salesforce or Dynamics 365: update contact
- Auth0 Universal Login → Customer identity providers: federate
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
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 studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study6bc242d3 - 01NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication (final, July 2025)csrc.nist.gov ↗
- 02Okta newsroom: Auth0 product innovations (21 May 2026)okta.com ↗
- 03Auth0 blog: Auth0 for AI Agents is generally available (19 Nov 2025)auth0.com ↗
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