You can build your own auth in a day. That’s the trap.
Dozens of B2B teams told us the same story. It starts as a simple login page. Then real traffic runs through it, and it quietly becomes identity infrastructure: the foundation your whole product stands on.
It looked like a feature. It left behind a whole identity model.
Every homegrown auth starts as a handful of lines. The trouble starts after launch, when each small decision quietly hardens into the model your whole product assumes is true.
Day one: forty lines of code
Email, password, hash it, store it, compare on login. Clean and done.
Day two hundred: a silent identity model
Who counts as a user. Which organization they belong to. Which session is still trustworthy. How access gets pulled back.
Year five: a foundation you can’t touch
Swapping the login page on paper meant rebuilding the identity foundation in code.
Homegrown auth runs fine — until the business moves
It logs people in for years without an incident. Then one business change turns “enough” into “in the way” overnight. These three arrive for almost every product that scales.
Enterprise customers start asking for SSO
The first big deal lands and procurement wants SSO through their own Entra or Google Workspace. Then both SAML and OIDC, because the next customer runs something else. Every customer’s identity setup is different, and almost none of the work carries over.
- Different protocols, field mappings, and certificate rotations per customer
- SSO isn’t built once. You rebuild it for every enterprise you sign
- It quietly becomes hand-work that only one engineer understands end to end
Identity that started scattered now has to be one
Split by organization, split by product, often inherited through acquisitions. “Unify identity” sounds like a feature; in code it means redefining what counts as one user and one organization.
- Can one email belong to several organizations? How do you migrate historical usernames?
- Nine products from acquisitions means nine auth stacks running in parallel
- Revoke a leaver across all of them at once, and audit it in one place
AI agents and CLIs start acting on a user’s behalf
It’s no longer just people in a browser. Agents, MCP servers, and command lines all claim to act for some user. And your auth only knows how to log a person into a page.
- Who is the token issued to, with what scope and what audience?
- Grant just one tool or one slice of data, then revoke it later
- MCP and CLI access lean on OAuth, not a login form
The real cost isn’t the build. It’s carrying it for years.
The first version is cheap: a few engineers, a few weeks, out the door. Then you feed it every year with the engineering time that belonged in your core product.
The bill just changed how it’s paid
You never get an invoice that says “authentication.”
It quietly rests on one or two people
The critical context lives in someone’s head, not the docs.
Where do you want your engineers?
No customer pays you a cent more because you wrote your own OAuth server.
If you don’t build it, how do you choose?
Most mature auth already covers the features: SSO, MFA, organizations, unified login, agent access. The real difference is whether you can leave. Don’t climb out of your own few thousand lines just to get locked into someone else’s.
Standard protocols, not an invented stack
A door you can actually walk through
Billing that doesn’t track your user table
Your data is never locked in
Auth probably isn’t your core business. Treat it that way.
Logto is open source, self-hostable, and also offered as a managed Cloud. Sign-in, MFA, SSO, and RBAC work out of the box on standard OIDC. Billing follows tokens, and the day you want to move out, the door stays open.