Build or Buy Authentication? An Honest Cost Comparison

Related: PostgreSQL vs MongoDB: How to Actually Choose in 2026

Authentication looks small. An email field, a password field, a button. Teams routinely budget a week for it and then spend two months on the parts nobody listed.

This is what the job actually contains, what providers cost, and when writing it yourself is a reasonable call.

What "authentication" really includes

The login form is maybe five percent of it. The rest:

• Registration, with email verification that actually arrives
• Password hashing with a current algorithm and sensible parameters
• Password reset, including expiring single use tokens
• Session management, refresh, and revoking sessions on demand
• Rate limiting on login, reset and registration
• Account lockout that stops attackers without letting them lock out your customers
• Multi factor authentication, and recovery codes for when someone loses their phone
• Social login, if you want it, for each provider separately
• Single sign on, if you ever sell to larger companies
• An audit trail of logins and security changes
• Handling email address changes without opening an account takeover path

Every item is a place to get it subtly wrong in a way that is invisible until someone exploits it.

The parts people get wrong

From reviewing a fair number of home-built systems, the same issues recur.

Password reset

The most common source of real vulnerabilities. Things that go wrong:

• Tokens that are predictable, because they were generated with a normal random function rather than a cryptographic one
• Tokens that never expire
• Tokens that stay valid after use, so anyone with the email link can reuse it
• Reset that does not invalidate existing sessions, so an attacker already logged in stays logged in
• Reset responses that reveal whether an email is registered

Timing and enumeration

If a wrong password takes 200ms and an unknown email takes 20ms, an attacker can work out which of your users exist. Same for different error messages on the two cases. Keep responses uniform in both wording and timing.

Sessions

Tokens stored where JavaScript can read them are exposed to any cross site scripting bug anywhere on your site. Prefer cookies marked HttpOnly, Secure and SameSite. Give sessions an expiry. Provide a way to revoke them all, and actually use it on password change.

Hashing

Use a modern password hash such as Argon2id or bcrypt at a sensible cost. Never a plain hash like SHA-256. Never anything home made.

What providers cost

Pricing is usually by monthly active user, with a free tier.

• Free tiers commonly cover several thousand monthly active users
• Paid tiers commonly land in the range of a few cents per active user per month
• Enterprise features, single sign on in particular, are frequently gated behind a much higher tier

Two traps:

• The single sign on jump. Many providers price normal auth cheaply and then charge a large step up for SAML or enterprise SSO. If selling to large companies is in your plan, check that number before you commit, not after a customer asks.
• Cost at scale. Per user pricing is excellent at ten thousand users and can be uncomfortable at a million. That is a good problem, and by then moving is a deliberate project rather than a surprise.

The honest recommendation

Buy it, unless you have a specific reason not to.

Not because you could not write it. Because it is security critical, the failure mode is a breach, and a provider has specialists who do nothing else. Your competitive advantage is almost certainly not your login page.

Good reasons to build it yourself:

• Data residency or regulatory rules that genuinely rule out a third party
• Scale where provider pricing is truly prohibitive and you have security expertise on staff
• An authentication model so unusual that no provider supports it
• You are offline or air gapped

Bad reasons:

• "It is only a login form"
• "We do not want another dependency"
• "It will be cheaper"
• "We want full control"

The last one deserves a note. You get control over behaviour you rarely need to change, in exchange for owning every vulnerability class in the list above, forever.

A middle option

Self hosted open source auth servers exist. You run the software, they provide the implementation. You keep data in your own infrastructure and avoid per user pricing, and you take on running it: patching, upgrades, availability.

This suits teams with real operations capability and a data residency requirement. It is not a shortcut for a small team that just wants to avoid a bill.

Support passkeys

Whatever you choose, support passkeys now. They are widely supported across browsers and devices. They remove passwords for the people who adopt them, which removes phishing, reuse and most reset traffic at once.

Keep another method available. Not everyone is ready, and device loss needs a path back in.

If you are building it anyway

Minimum bar before it touches real users:

1. Argon2id or bcrypt, never a bare hash
2. Reset tokens from a cryptographic random source, expiring within an hour, single use
3. Rate limiting on login, reset and registration, by IP and by account
4. Identical responses and timing for unknown email and wrong password
5. HttpOnly, Secure, SameSite cookies with an expiry
6. All sessions invalidated on password change
7. Multi factor available, with recovery codes
8. An audit log of security events
9. A penetration test by someone who did not write it

If any of those is missing, the system is not finished.

We build both patterns depending on what a project needs. If you want a view on which fits yours, get in touch.