Auth0 sign-in that customers finish, and agents can't abuse.
We build Auth0 tenants for consumer and B2B apps, migrate users off homegrown login without forcing password resets, and wire up Auth0 for AI Agents when your product starts acting on users' behalf.
Auth0 for AI Agents, generally available 19 Nov 2025
Latest GA
Auth for MCP and On-Behalf-Of Token Exchange, 21 May 2026
Agent building blocks
Token Vault, asynchronous authorization, FGA for RAG
release watch
Auth0 for AI Agents generally available19 Nov 2025
Auth for MCP and On-Behalf-Of Token Exchange21 May 2026
connects with
in short·15-second read
Cohash implements Auth0 for customer and B2B identity.
We design tenants, Universal Login, Organizations, Actions and user migration from legacy stores. When an application adds AI agents, we configure Auth0 for AI Agents. That includes Token Vault for third-party API access, asynchronous authorization for human approval, and Auth for MCP, which Auth0 made generally available in May 2026.
you probably need this if
Sign-in runs on a homegrown table of password hashes that every pen test flags.
Business customers ask to sign in with their own Okta or Entra ID, and every one of those turns into a custom build.
Customer profiles in Salesforce or Dynamics drift from what users see in their account settings.
19 Nov 2025Auth0 for AI Agents generally available User Authentication, Token Vault, Asynchronous Authorization and Fine-Grained Authorization for RAG. source ↗
21 May 2026Auth for MCP and On-Behalf-Of Token Exchange Both reached general availability, and FGA Permissions Index shipped as a developer preview. source ↗
today · Oct 22, 2026
the story · auth0 estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Auth0 estate, 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 · auth0 estate3 open
openSign-in runs on a homegrown table of password hashes that every pen test flags.
recurringBusiness customers ask to sign in with their own Okta or Entra ID, and every one of those turns into a custom build.
blockedCustomer profiles in Salesforce or Dynamics drift from what users see in their account settings.
exposure
Tenant design and Universal LoginUser migrationB2B and OrganizationsActions and extensibilityAuth0 for AI AgentsAttack protection and MFA
startrehearsehandover
Tenant or login review
Tenant and login design
Migration rehearsal
Launch and CRM sync
Handover
we are here
ready to hand over
Users keep their passwords and notice nothing on day one.
Onboarding a new enterprise customer is now a script and a checklist.
Tenant configuration in source control, deployed with the Auth0 Deploy CLI
User migration plan with rehearsal results from a copy of the legacy store
chapter 01 · where it hurts
Why teams reach out
Sign-in runs on a homegrown table of password hashes that every pen test flags.
Business customers ask to sign in with their own Okta or Entra ID, and every one of those turns into a custom build.
Customer profiles in Salesforce or Dynamics drift from what users see in their account settings.
chapter 02 · what we change
How we solve it
Tenant design and Universal Login
User migration
B2B and Organizations
Actions and extensibility
Auth0 for AI Agents
Attack protection and MFA
chapter 03 · how it runs
Our approach
Tenant or login review
Tenant and login design
Migration rehearsal
Launch and CRM sync
Handover
chapter 04 · where you end up
What changes
Users keep their passwords and notice nothing on day one.
Onboarding a new enterprise customer is now a script and a checklist.
Tenant configuration in source control, deployed with the Auth0 Deploy CLI
User migration plan with rehearsal results from a copy of the legacy store
what we do
Our Auth0 work
6 kinds of Auth0 work, each run by engineers who have done it on live tenants.
Development, staging and production tenants, custom domains, branding and a Universal Login flow tested on real devices. Tenant settings kept in source control so changes are reviewed.
Automatic migration through a custom database connection, so users move on their next sign-in, or a bulk import when password hashes are compatible. We plan the cut-over with your support desk.
Organizations, enterprise connections to your customers' Okta or Entra ID tenants, and invitation flows so each business customer manages its own users.
Post-login and pre-registration Actions for enrichment, progressive profiling and fraud checks, versioned and tested like the rest of your code.
Token Vault so agents call Google, Slack or GitHub with the user's consent, asynchronous authorization for approvals on sensitive actions, and fine-grained authorization so retrieval only returns documents the user may see.
Bot detection, breached password detection, brute-force limits and MFA policies tuned against your real traffic instead of left on defaults.
capability 01 / 06in production
Tenant design and Universal Login
Development, staging and production tenants, custom domains, branding and a Universal Login flow tested on real devices. Tenant settings kept in source control so changes are reviewed.
Automatic migration through a custom database connection, so users move on their next sign-in, or a bulk import when password hashes are compatible. We plan the cut-over with your support desk.
Organizations, enterprise connections to your customers' Okta or Entra ID tenants, and invitation flows so each business customer manages its own users.
Token Vault so agents call Google, Slack or GitHub with the user's consent, asynchronous authorization for approvals on sensitive actions, and fine-grained authorization so retrieval only returns documents the user may see.
We pieced these together from Auth0 situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Two million users in a Postgres table with bcrypt hashes
composite · not a client story
Beforethe situation
A consumer app keeps its users in its own Postgres database with bcrypt hashes and a homegrown reset flow. Pen tests flag the reset tokens every year, and marketing wants social login before the spring campaign.
What we dothe work
We confirm the hashes can be bulk imported and run the import into a staging tenant first. Universal Login with social connections goes live behind a feature flag. The old reset endpoint is removed once sign-in traffic has moved.
Afterwhere you end up
Users keep their passwords and notice nothing on day one. The homegrown reset flow is deleted, and social login ships on the same user store instead of a second one.
case file 02
B2B SaaS where every enterprise customer wants its own SSO
composite · not a client story
Beforethe situation
Forty enterprise customers sign in through their own Okta or Entra ID. Each connection was set up by hand with no naming rules, and onboarding a new customer takes a support engineer most of a week.
What we dothe work
We put every enterprise customer in its own Auth0 Organization with its connection attached, and script the setup through the Management API. Customer admins manage their own users through an invitation flow.
Afterwhere you end up
Onboarding a new enterprise customer is now a script and a checklist. Users stay in their own Organization, and nobody edits connections by hand.
We don't start a step until the last one has produced something you can check.
step 01
Tenant or login review
First we read the tenant: settings, connections, Actions and logs. New to Auth0? Then we read your current login code and user store instead, and list what needs deciding before anything is built.
step 02
Tenant and login design
Development, staging and production tenants, a custom domain, Universal Login and Organizations planned up front, with tenant configuration exported to source control through the Auth0 Deploy CLI.
step 03
Migration rehearsal
We test a custom database connection with automatic migration against a copy of the legacy user store. That way we see how sign-in, password resets and duplicate emails behave before a real user hits them.
step 04
Launch and CRM sync
We shift traffic to Universal Login a slice at a time and watch the tenant logs as it goes. Meanwhile we check that post-login Actions are keeping Salesforce or Dynamics 365 contacts up to date.
step 05
Handover
Runbooks for tenant changes and Action deploys, and for tuning attack protection. Plus a plain read of what drives your monthly active user count.
ai on auth0
Where AI fits on Auth0, and where it needs guardrails.
Auth0 for AI Agents went GA in November 2025, shipping with Token Vault and asynchronous authorization, plus FGA for RAG. Auth for MCP followed in May 2026, and a beta MCP server for tenant management exists too. Product teams can have agents act for users with consent and approvals. Getting the scopes right, and the negative tests, matters more than setup.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Auth0does the work
Auth0 has a beta MCP server for its Management API and advises against using it in production. By default it requests no scopes. Add --read-only and --tools and you limit it further. Your own MCP servers should sit behind Auth for MCP, with per-tool scopes and logging. Writes need approval.
Token Vault for third-party APIs
Token Vault keeps the user's tokens (Google, Slack, GitHub) so the agent can call those services once the user has consented. We decide per agent which connections it gets, and we write a test that fails if a token ever lands in the model's context.
Asynchronous authorization
When an agent tries something sensitive, it holds until the user approves on another device. Which actions get that treatment is our call (payments and account changes, say), and we test what happens when the approval times out.
Auth for MCP and On-Behalf-Of Token Exchange
Both went GA on 21 May 2026. Register your MCP server as an API, one scope per tool. Our tests then go after the tools the user never allowed. Those calls should fail, and we check that they do.
Fine-Grained Authorization for RAG
Retrieval results pass through FGA first, so an agent gets only the documents the user may see. Your app's sharing rules become the relationship model. To check it, we run queries as users whose access we already know.
How Auth0 connects your apps, your users and your CRM
Users come in from web, mobile and agent clients and land on Universal Login, which checks their credentials against the right connection. Legacy users are migrated on first sign-in. After login, Actions push profile changes to Salesforce or Dynamics 365, and the third-party tokens agents use sit in Token Vault.
01 · Applications
Web appSPA · server-rendered → Universal Login · OIDC sign-in
Mobile appiOS · Android → Universal Login · OIDC with PKCE
AI agentacts for the signed-in user → Token Vault · token exchange
These are working documents, written against your configuration, so your team can run them without us.
evidence01
Tenant configuration in source control, deployed with the Auth0 Deploy CLI
yours to keep
tests02
User migration plan with rehearsal results from a copy of the legacy store
yours to keep
tests03
Actions code with unit tests and a versioned deploy pipeline
yours to keep
runbook04
Runbook for adding a new B2B customer's enterprise connection
yours to keep
document05
Attack protection settings tuned against your tenant logs, with the reasoning
yours to keep
tests06
Scope map for each MCP server and agent, with tests for calls that must fail
yours to keep
talent and delivery · auth0
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.
Put these to anyone bidding on your Auth0 work. The ones who've done it answer differently from the ones who've read about it.
Q1
Can we bulk import our password hashes, or will users migrate on their next sign-in?
This answer sets the timeline. Supported hash formats import in a single batch. Anything else needs a custom database connection running both stores side by side until the inactive users are dealt with.
Q2
How will you keep tenant configuration in code review instead of the dashboard?
Changes made by hand drift between development, staging and production. Exporting tenant configuration with the Deploy CLI or Terraform is what makes a rollback possible.
Q3
Which Actions run on every login, and what happens when one times out?
Post-login Actions sit on the critical path. A slow call to a CRM or fraud API inside an Action can stall sign-in for everyone, so timeouts and fallbacks need design and testing.
Q4
How do you plan to test that a token issued to an agent can't reach a tool the user never approved?
Auth for MCP and Token Vault give agents delegated access. The failure that hurts is a scope that's too broad, and you only find it with negative tests written to catch it.
Q5
What counts toward our monthly active users, and how will the design change it?
Auth0 charges by active users. Test accounts and bot sign-ups can push that count up, so find out what counts before launch instead of at renewal.
01What drives the cost of an Auth0 implementation?
Mostly the number of applications, how users are migrated and how much custom logic lives in Actions. A single app with social login is small work. Several apps, B2B Organizations with enterprise connections, and a lazy migration from a legacy database take longer. The Auth0 subscription itself is priced separately by Okta.
02Should we use Auth0 or Okta Workforce Identity?
Auth0 is for customer-facing and B2B applications. Employees and contractors signing into business apps belong in Okta Workforce Identity. Plenty of companies run both, and we help work out where each type of user should go.
03Can you secure the MCP server our agents use?
Yes. Auth0 made Auth for MCP generally available in May 2026. We register the MCP server as an API, set scopes per tool, and test that a token issued to an agent can't reach tools the user never allowed.
04Do you also migrate from Cognito, Firebase or a custom user table?
Yes. It comes down to whether we can export the existing password hashes. If we can, it's a bulk import. If we can't, a custom database connection moves each user over the next time they sign in.
05How long does a move from a homegrown login to Auth0 take?
It depends on how many applications share the login, whether the password hashes can be exported, and how much logic sits in the current sign-up flow. One app with importable hashes is a short project. Several apps and an on-sign-in migration that runs until inactive users age out take longer. We size it after reading the current code and user store.
services
Related services
Projects on Auth0 usually end up touching one of these, so they're worth a look.
