The question is almost never which authentication provider is best. It is whether you should be writing authentication yourself, and most teams answer that once, early, with bad information, and then live with the answer for years.
The bad information is that auth looks small. A signup form, a login form, a hashed password, a session cookie. Two days of work, and for a fortnight it genuinely is two days of work. What makes it expensive is not the first version. It is everything that arrives afterwards, each piece individually reasonable, none of it on the roadmap, all of it landing on whoever wrote the first version.
I spent eleven years at LoginRadius building and running a customer identity platform, going from junior developer to VP of Product and Engineering, on a system serving around 3,000 businesses and 400 million end users. The thing that struck me repeatedly was not the sophistication of what we built. It was how many of our customers had built the same thing first, badly, and were migrating away from their own code because the maintenance had become a permanent tax on a team that wanted to be building the product.
So this article is a map rather than a ranking. What in-house auth actually costs over three years, what you are really buying when you buy a provider, and a category map that routes you to the article for your situation.
Key takeaways
- The cost of in-house auth is not the login form. It is password reset, session revocation, bot signups, breach response and the SSO your first enterprise customer demands, arriving one at a time over three years.
- Authentication and authorization are different problems with different vendors. Buying one does not solve the other, and conflating them is the most common architectural mistake in this category.
- The two decisions that are genuinely hard to reverse are where user records live and how sessions are represented. Everything else is replaceable with effort.
- Your buyer profile matters more than any feature grid. Consumer scale, B2B multi-tenancy and internal workforce identity are three different products sold under one word.
What in-house auth costs over three years
Build the login form. It works. Now count what follows, because this is the list nobody estimates.
Password reset. Not the email, the token. Single use, time limited, invalidated when the password changes, invalidated when a second reset is requested, and resistant to user enumeration so an attacker cannot learn which addresses have accounts from the response. Then the reset email lands in spam, and you discover that email deliverability is now a system you own.
Session revocation. The day someone logs out of a stolen session and it keeps working, you learn what you chose when you picked stateless JWTs. Revoking a token you deliberately made self-validating means adding the state back, which means a store on the hot path of every request. That store becomes one of the highest-QPS services you operate, and it is on the critical path of everything. This is a real decision with real consequences, covered in session management libraries.
Bot signups. A few months after launch your signup endpoint is being hammered by scripted registrations. They burn your email sending reputation, poison your activation metrics and sometimes exist to test stolen card numbers against your billing integration. Defending against this is an ongoing arms race, not a feature you ship once.
MFA, and then MFA recovery. TOTP enrolment is a weekend. What is not a weekend is what happens when a user loses the device: recovery codes, their storage, their single-use semantics, and a support process that does not become the easiest way to take over an account. The recovery path is where MFA implementations actually fail, which is why MFA providers are evaluated on recovery design more than on enrolment.
Breach response. Somebody else is breached, credential stuffing starts against your login endpoint, and you need rate limiting per account rather than per IP, anomaly detection, and a forced password rotation flow with communications attached. You need this in hours, not sprints.
SSO for the first enterprise customer. This is the one that reliably breaks the build decision. A deal worth more than your current ARR is contingent on SAML, and your auth system has exactly one concept of a user with exactly one way to log in. Adding per-organization identity provider configuration to a system that never had organizations is not a feature, it is a rewrite of your user model. Two engineer-weeks per customer is the realistic figure once you account for the per-tenant quirks, which is the subject of enterprise SSO solutions.
Protocol drift. OAuth 2.0 best practice moved to PKCE for public clients. Implicit flow was deprecated. Browsers changed cookie defaults, then changed third-party cookie behaviour, and every implementation that relied on a cross-site iframe broke. Passkeys arrived and users started asking why you do not support them. None of this is optional work and none of it produces a feature your customers notice.
Add those up and in-house auth is roughly a part-time engineer indefinitely, spiking to full-time in the weeks after a security disclosure or an enterprise deal. Over three years that is a meaningful fraction of a salary, spent on a system where the best possible outcome is that nobody notices it.
Needs first-hand data: Open your issue tracker and your git history and count every ticket, commit and incident that touched authentication over the last twelve months. Convert to engineer-days. That single number, for your own team, settles the build versus buy argument more convincingly than any vendor pricing page, and almost nobody has ever measured it.
When building it yourself is still right
Buying is not automatically correct, and the honest cases for building are specific.
You have a hard data residency or air-gap requirement that no hosted vendor satisfies. You are at a scale where per-user pricing exceeds the fully loaded cost of an identity team, which genuinely happens for consumer products with tens of millions of accounts. Your auth is an unusual shape that no provider models well, such as authentication against a physical device fleet or a licensing system. Or authentication is your product.
There is also a middle path that did not exist five years ago: run an open-source identity server yourself. Keycloak, Ory, Zitadel, Authentik and SuperTokens all give you a real, standards-complete implementation without a per-user meter, and you pay in operations rather than licence. That is a genuine third option, not a compromise, and it is covered in open source authentication and self-hosted identity providers.
What is almost never right is the thing most teams actually do, which is build a password login now and promise to revisit it later. The revisit happens under deal pressure, with a user table full of hashes in a format your new provider may not accept, which is the whole story of migrating off Auth0 or anything else.
The four things you are actually buying
A provider sells one bundle, but underneath it there are four separable products, and knowing which you need stops you overbuying.
Authentication. Proving who someone is. Passwords, social login, magic links, one-time codes, passkeys, and the flows around them: reset, verification, step-up. This is the part everyone means when they say auth.
Session and token management. What happens after login. Cookie flags, token lifetimes, refresh rotation, revocation, and the behaviour of all of it across web, mobile and API clients. Structurally the most important part and the least discussed.
Authorization. What someone is allowed to do. Roles, permissions, resource-level rules, relationship-based access. Most authentication providers ship a basic role model and stop, because real authorization is a separate hard problem with its own vendors. See authorization and permissions services.
Enterprise connectivity. SAML and OIDC federation to customer identity providers, SCIM user provisioning, directory sync, audit logs, custom domains. This is a distinct product that some vendors sell entirely on its own.
The mistake to avoid is assuming the bundle is uniform in quality. Plenty of providers are excellent at authentication and shallow at authorization. Some are almost purely enterprise connectivity with a thin login layer attached. Ask which of the four is the vendor’s actual centre of gravity, because that is the part that will be good.
The category map
Three buyer profiles cover nearly everyone, and they want different products.
Consumer scale. Millions of end users, social login breadth, progressive profiling, consent and preference management, GDPR deletion at volume, and bot registration defence. This is CIAM, and the economics are dominated by cost per user at large numbers. Start at CIAM platforms.
B2B SaaS. Fewer users, but they belong to organizations, and the organization is the real unit. Per-tenant SSO configuration, role delegation to customer admins, invitations, SCIM provisioning, custom domains. Start at auth providers for B2B SaaS.
Workforce identity. Your own employees logging into internal systems and SaaS tools, with joiner-mover-leaver processes and device posture. This is a different market with different vendors, and it is the reason Okta alternatives has to separate workforce from customer identity before it can answer anything.
Then route by what is actually blocking you.
| Your situation | Start here |
|---|---|
| Pre-launch, need login this week | Auth providers for startups |
| First enterprise deal wants SAML | Enterprise SSO solutions |
| Multi-tenant B2B with customer admins | Auth providers for B2B SaaS |
| Millions of consumer accounts | CIAM platforms |
| Cannot send user data to a vendor | Self-hosted identity providers |
| Want no licence cost, will run it | Open source authentication |
| Auth0 bill or lock-in is the problem | Auth0 alternatives |
| Choosing between the obvious three | Clerk vs Auth0 vs WorkOS |
| Permissions are the hard part, not login | Authorization services |
| Enterprise asked for user provisioning | SCIM provisioning tools |
| Killing passwords | Passwordless authentication |
| Shipping passkeys specifically | Passkey and WebAuthn providers |
| Adding a second factor | MFA providers |
| Sessions, tokens and revocation | Session management libraries |
| Building on Next.js App Router | Auth solutions for Next.js |
| Authenticating machines, not people | API authentication tools |
| iOS and Android token storage | Auth solutions for mobile apps |
| Regulated onboarding, real identity | Identity verification and KYC tools |
How to choose
Four questions, in this order. The first two eliminate most of the market.
One. What is the unit of your product: a person or an organization? If users belong to companies and those companies have admins, you need organization primitives in the data model from day one. Retrofitting them is the single most expensive migration in this category, worse than changing vendors. A consumer product with a shared user pool has the opposite problem and should not pay for tenancy machinery it will never use.
Two. Where must the user records live? Vendor cloud, your cloud, a specific region, or your own database. This is a compliance question, not a preference, and it is the constraint that removes the most candidates fastest. Answer it before you look at a single feature list.
Three. What is the exit path? Specifically: can you export password hashes in a format another system will accept, and do user identifiers stay stable across a migration? Most providers will export something. The question is whether your users will have to reset their passwords on the way out, because that is a migration with a visible failure rate and a support cost, not a background task.
Four. Only now, features. And evaluate them by building the same three flows in each candidate: signup with email verification, login with a second factor, and one enterprise organization with SSO configured by somebody who is not you. That third flow is the one that separates the products, and it is the one demos skip.
Two things to check that nobody puts on a comparison grid. Are the audit logs exportable to your own log pipeline, because log management is where security investigations actually happen and a vendor console with ninety days of retention will not satisfy an auditor. And what is the documented behaviour when the provider is unreachable: does your application fail closed, fail open, or keep running on cached sessions until they expire. Every provider has an answer and very few volunteer it.
Needs first-hand data: Take one identical B2B application and implement it end to end on three providers: signup, organization creation, inviting a teammate, and configuring SAML for one test tenant against a real identity provider. Record elapsed engineering hours per provider and, separately, hours spent reading documentation versus writing code. That ratio is the most honest signal of developer experience there is, and no vendor publishes it.
Frequently asked questions
Is it ever cheaper to build authentication in-house?
At very large consumer scale, sometimes yes, because per-user pricing eventually exceeds the fully loaded cost of a small identity team. But the crossover is much further out than teams assume, and it only holds if you count the whole job: reset flows, revocation, bot defence, MFA recovery, breach response, protocol upgrades and enterprise federation. Teams that compare a vendor invoice against the cost of a login form always conclude that building is cheaper, because they compared the wrong things.
What is the difference between authentication and authorization?
Authentication establishes who someone is. Authorization decides what they may do. They fail differently and they scale differently: authentication happens once per session, authorization happens on every request, which is why authorization latency is a design constraint and authentication latency mostly is not. Most authentication providers include a simple role model that is adequate until it suddenly is not.
Can I switch providers later?
Yes, but the cost is concentrated in two places. Password hashes must be exportable in a format the new provider can verify, or every user resets their password during the cutover. And user identifiers must stay stable, or every foreign key in your database pointing at a user needs remapping. Providers that support verifying an imported hash on first login give you a silent migration. Providers that do not give you a visible one.
Do I need a provider if I only use social login?
You still need the parts around it. Account linking when the same person arrives through two different social providers, sessions and revocation, what happens when a user removes your app from their Google account, and eventually the enterprise customer whose employees cannot use personal social accounts at all. Social login removes password storage. It does not remove identity management.
Related reading
- Best auth providers for startups — free tiers, MAU pricing cliffs, and the month the auth bill overtakes hosting.
- Best auth providers for B2B SaaS — multi-tenancy models, admin delegation, and the requirements that arrive with the first enterprise deal.
- Best enterprise SSO solutions — SAML versus OIDC in practice and why each customer integration costs two engineer-weeks.
- Best open source authentication — what you take on operationally when there is no vendor to page.
- Clerk vs Auth0 vs WorkOS — three different bets on the same problem, compared on architecture.
- Best authorization and permissions services — the half of the problem authentication providers do not solve.