Should You Build Authentication In-House?
About this ebook
Most teams should not build authentication in-house. I say that as someone who did: I founded LoginRadius and scaled it to more than 1 billion users. This ebook is for the teams that will build it anyway, or have to.
Some have good reasons: unusual regulatory constraints, extreme scale where per-user pricing breaks the business, an identity product they sell, or an existing homegrown system they must modernize. Others are about to make an expensive mistake. Both deserve a practitioner's map instead of a stack of blog posts.
Who it is for
- CTOs and architects deciding whether to build or buy
- Engineering teams that already own a homegrown login and need to bring it up to 2026 standards
- Security engineers reviewing an in-house identity system
- Founders building an identity, security, or developer-platform product
How to read it
Chapters 1 and 2 are the decision and the architecture. Chapters 3 to 12 are the build, layer by layer, in the order I would build them. Chapters 13 to 18 cover what keeps it alive: security, keys, scale, regional data, compliance, and operations. Chapters 19 and 20 are the launch checklist and a phased roadmap.
Most chapters close with the mistakes I see most often, then a few key takeaways. Read the mistakes even if you skip the rest.
The honest warning
Authentication is never finished. Browsers change WebAuthn behavior, standards bodies publish new guidance, attackers adapt, and auditors ask new questions every year. If you build, budget for a permanent team, not a project.
Editorial independence
I have no commercial relationship with any vendor or library named here. Parameters, standards, and laws cited reflect sources checked in November 2026. Cryptographic guidance changes, so verify current recommendations before you ship. Nothing in this ebook is legal advice.
The short answer
Build only if authentication is part of your product or your constraints rule out every vendor. In almost every other case, buying is cheaper, safer, and faster.
The first version of a login form takes a week. A production identity platform takes years, because the hard part is not the happy path. It is account recovery, enterprise SSO edge cases, key rotation, credential stuffing at 3 a.m., a SOC 2 auditor's questions, and a browser update that quietly changes how passkeys behave.
When building is the right call
| Situation | Why building can make sense |
|---|---|
| Identity is your product | You sell an identity, security, or developer platform. Owning the core is the business. |
| Extreme consumer scale | At tens of millions of monthly active users, per-user pricing can exceed the cost of a dedicated team. Model it honestly, including the team. |
| Hard regulatory or sovereignty limits | Data must stay in a jurisdiction, an air-gapped network, or a government cloud no vendor serves. |
| Unusual authentication | Hardware devices, offline-first apps, kiosks, shared family devices, or custom assurance levels that vendors do not support. |
| An existing homegrown system | You already own it. The question is not build vs buy but modernize vs migrate. |
When building is the wrong call
- You want to avoid a vendor bill at under a few hundred thousand users. The engineers will cost more.
- You want "more control" without a specific requirement no vendor meets.
- You do not have at least two engineers who will own identity permanently.
- Nobody on the team has shipped OAuth, SAML, or WebAuthn in production before.
The real cost
These are my planning estimates from building and running identity systems, not published benchmarks. Use them to start the conversation, then model your own.
| Phase | Scope | Typical team |
|---|---|---|
| Minimum viable login | Email and password, sessions, email verification, reset, rate limiting | 2 engineers, 2 to 3 months |
| Consumer-grade | Plus passkeys, MFA, social login, breached-password checks, account recovery, audit logs | 3 to 4 engineers, 6 to 9 months |
| Platform-grade | Plus OAuth and OIDC provider, SAML SSO, SCIM, multi-tenancy, admin console | 5 to 8 engineers, 12 to 18 months |
| Enterprise-grade | Plus multi-region, data residency, SOC 2 and ISO 27001, 99.99% target, 24x7 on-call | A permanent team of 8 or more |
Add the costs teams forget: penetration tests, bug bounty, audits, on-call compensation, HSM or KMS fees, SMS and email delivery, and the opportunity cost of what those engineers would otherwise ship.
A middle path most teams should consider
You do not have to choose all or nothing. Many strong teams buy the commodity layers and own the experience:
- Use mature open-source building blocks for protocols (a certified OpenID Connect library, a maintained SAML library, a WebAuthn server library) instead of writing parsers and cryptography yourself.
- Run an open-source identity server you can self-host and extend.
- Buy the identity provider, own the login UI and the risk policy. This is where brand experience and fraud logic live.
My rule: buy the commodity, own the product. The rest of this ebook assumes you have decided to build anyway, and shows how to do it properly.
If the analysis points to buying, CIAM Compass compares customer identity vendors on the same capability matrix, and the CIAM Buyer's Handbook walks through the purchase. For the experience layer you keep either way, Login Without Friction covers passkeys, MFA, and recovery design from the brand side.
Common mistakes
- Comparing a vendor invoice against zero engineering cost.
- Treating identity as a one-quarter project with no long-term owner.
- Writing your own cryptography, JWT parser, or XML signature validator.
Key takeaways
- Build only if identity is your product or your constraints rule out every vendor.
- A login form takes a week; a production identity platform takes years and a permanent team.
- Count the costs teams forget: pen tests, audits, on-call, KMS fees, message delivery, and opportunity cost.
- Buy the commodity layers, own the login experience and the risk policy.