Build vs Buy Authentication: The Real Cost of Rolling Your Own Auth - Part 2

Should you build or buy authentication, and how do you choose a provider?

For most teams, the answer is buy. A managed provider ships in an afternoon, inherits a security and compliance posture you'd otherwise build and audit yourself, and covers enterprise features like SSO, SCIM, and RBAC that you'll eventually need. Build only when a hard constraint forces it.

Among managed providers, Clerk is a strong default: fast setup, broad auth methods, native B2B and organizations, and low data lock-in. The honest caveats are that its enterprise pricing is custom and that deep UI customization beyond theming means building flows with hooks.

This is Part 2 of a two-part series on building authentication versus buying a managed provider. Part 1 makes the cost case; this part is the decision itself: build versus buy feature by feature, when each one fits, how to choose a provider, where Clerk lands, and how little code it takes to reach a working sign-in.

Making the Decision: Start Here

Part 1 landed on a clear conclusion. For most teams, buying a managed provider wins on time-to-ship, total cost, and security, and building your own is worth it only in a narrow set of cases (Part 1). The real decision usually comes before you shortlist vendors: build or buy at all.

This part is the second half of that decision — where sizing the cost turns into an actual choice. If Part 1 asked whether building is worth it, this part is how to tell which side you're on and, if you're buying, how to choose a provider well.

Feature Parity: What You'd Build vs. What You Get

Here's the same capability set two ways: what you'd build and maintain yourself, and what you get from a managed provider (using Clerk as the concrete example). Every Clerk caveat stays in the table on purpose, because the caveats are what keep the comparison honest.

Reading the table: build effort vs. included capability

Take the Passkeys row. Building it means the full WebAuthn relying-party ceremonies for registration and authentication, attestation verification, signature-counter tracking to catch cloned authenticators, and cross-browser upkeep as the spec and browsers keep moving — WebAuthn is now on Level 3, still a Candidate Recommendation⁠, while Level 2⁠ is the settled 2021 baseline. The managed cell is a toggle. Read every build cell the same way.

When Building Your Own Auth Makes Sense

Building your own authentication is the right call in a few genuine cases. They're narrower than most build-it-yourself instincts suggest.

Regulated, government, or defense work that bars third-party identity infrastructure. Some environments legally cannot hand identity to a commercial SaaS. DoD Impact Level 5 workloads require physical tenant separation and US-persons-only operator access (Microsoft Learn⁠). Federal systems often require PIV/CAC smart-card authentication (FIPS 201-3, 2022⁠) and alignment with NIST SP 800-63-4 (finalized 2025-07-31, NIST⁠). login.gov exists because the government chose to build its own (login.gov⁠). The honest counterpoint: a commercial provider can reach government-grade compliance. Descope hit FedRAMP High in 2025 (Descope, 2025⁠). IL5 needs more than FedRAMP High, so even in true must-build cases, "build" usually means self-hosting on authorized infrastructure rather than hand-writing OAuth.

You already have a dedicated security team that treats auth as core infrastructure. If identity is your product, or a team already owns it full-time, the calculus shifts. Treat the headcount as a standing budget line rather than a one-time project. There's no clean industry "3 to 5 engineers" figure here; for scale, IANS finds roughly 1.5 security FTEs per 100 employees at companies under $50M in revenue (IANS, 2025⁠). This is the weakest-sourced of the four cases, so keep it directional.

Strict data residency, sovereignty, or air-gapped requirements. Residency (where data physically sits) and sovereignty (which government can legally compel it) are different problems (Kiteworks⁠). The US CLOUD Act can compel US providers to produce data within their possession, custody, or control, regardless of where it's stored (18 U.S.C. §2713⁠), so self-hosting is the strongest sovereignty answer, at a real operational cost. Air-gapped systems are definitional: if no cloud SaaS is reachable, a cloud auth provider is off the table.

Learning projects and prototypes. Building auth to understand it is a good reason to build auth. Lucia, once a library, now exists mostly as a resource for learning to implement authentication from scratch (Lucia⁠). Just don't ship the learning project to production and call it done.

There's a middle path between buying a SaaS and hand-rolling everything: self-host a maintained identity server like Keycloak (Apache 2.0, a CNCF incubating project, Keycloak⁠) or Ory (Ory⁠). You still deploy, patch, and operate someone else's audited server, which is an ongoing operations burden, but you skip designing the protocol logic and owning every security bug in it. That's a different job from rolling your own.

When Buying Managed Authentication Makes Sense

For most teams, this is the case. Part 1's cost and risk evidence points here: the tiered build cost, the maintenance treadmill, and the breach liability all favor buying unless a hard constraint says otherwise. Lean toward a managed provider when:

How to Choose an Authentication Provider

If you're buying, evaluate providers against the same neutral criteria no matter who wrote the guide. These are grounded in an independent buyer framework (CIAM Buyer's Handbook⁠) and in vendor guidance worth reading critically (MojoAuth, 2026⁠).

Evaluation criteria checklist

Questions to ask before you commit

Ask these before you sign, and get the answers in writing:

• Migration in and out: how do users get in, and how do they get out?
• Hash import: can you bring existing bcrypt or scrypt hashes so users don't all have to reset their passwords?
• Open standards: OIDC, SAML, OAuth 2.0, and SCIM?
• Data ownership: what happens to your data if you stop paying?
• Total cost of ownership: including egress and professional-services fees (IdentityFusion⁠).
• Enterprise features: shipped today, or on a roadmap?

Where Clerk Fits

Why Clerk is a strong default

Clerk is a strong default for the majority of teams that should buy. Setup is fast: you can reach a working sign-in in minutes (the code below shows how little it takes). It covers broad auth methods out of the box, including social, passwordless, passkeys, and MFA (Clerk Docs). You get prebuilt components for the common flows plus headless hooks when you need to build your own.

Organizations and B2B multi-tenancy are built in. Sessions are managed for you as a 60-second token refreshed roughly every 50 seconds (Clerk Docs). Directory Sync (SCIM) and enterprise SSO are both GA (Clerk changelog, 2026). You inherit Clerk's SOC 2 posture instead of building your own. And data lock-in is low: you can export every user, including password hashes (the FAQ has the exact mechanism).

Honest limitations to weigh

Three limitations are worth weighing before you commit.

1. Enterprise pricing is custom and unpublished. The Hobby, Pro, and Business tiers are on the pricing page, but Enterprise is "talk to sales," and Enterprise SSO connections bill per connection past the first included one. That's the honest version of the "SSO tax" (sso.tax⁠) applied to Clerk itself.
2. Deep UI customization beyond theming means building flows with hooks. Theming itself is quick: install @clerk/ui, then pass a prebuilt theme to the appearance prop — import { dark } from '@clerk/ui/themes' and set appearance={{ theme: dark }} on <ClerkProvider> (Clerk Docs). Going past what theming covers means driving the flow yourself with headless hooks like useSignIn() and useSignUp(), which is real multi-step state and error handling (Clerk Docs).
3. Clerk depends on third-party infrastructure. It runs on Cloudflare, Vercel, and Google, so restrictive-network environments in some countries can affect access (Clerk CSP docs).

A few smaller gates matter when you plan. A passkey sign-in can satisfy MFA on its own, but passkeys can't be enrolled as a dedicated MFA method. MFA, passkeys, and production SSO all need a paid plan. Bot protection ships off by default, so you turn it on (Clerk Docs). Audit-log retention is tier-gated to 1, 7, 30, or custom days (Clerk Docs).

On reliability, look at the record rather than a vibe. Clerk posted a public postmortem for a roughly 26-minute outage on March 10, 2026, and said afterward it "shifted the majority of our engineering team to reliability-focused projects" (Clerk, 2026). A dated postmortem you can read is worth more than an outage count with no context.

On compliance, the tiering is specific. A Business plan includes the SOC 2 report and the HIPAA artifacts, while a signed HIPAA BAA (the control that actually makes you HIPAA-compliant) is Enterprise-only (Clerk changelog, 2026). Clerk advertises SOC 2 Type II, HIPAA, GDPR, and CCPA for itself (Clerk); it doesn't claim its own ISO 27001 or PCI DSS, which belong to its infrastructure providers.

One naming note. Where Clerk's connection types list EASIE, that's Clerk's own OIDC-based enterprise-SSO option for Google Workspace and Microsoft Entra ID. SAML and OIDC are the portable open standards; EASIE is a Clerk feature built on top of Google and Microsoft OIDC.

Getting Started: What Implementation Looks Like

Buying: time to first login with a managed provider

Wiring up sign-in with a managed provider takes only minutes. With Clerk and Next.js, install @clerk/nextjs, then add your publishable and secret keys to .env.local.

Add the middleware. On Next.js 16 the file is proxy.ts:

import { clerkMiddleware } from '@clerk/nextjs/server'

export default clerkMiddleware()

export const config = {
  matcher: [
    // Skip Next.js internals and static files unless found in search params
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
    // Always run for API routes
    '/(api|trpc)(.*)',
  ],
}

clerkMiddleware() makes the session available across your app. On Next.js 15 and earlier, the identical code lives in middleware.ts; only the filename changes.

Then wrap your app. <ClerkProvider> goes inside <body>, and the prebuilt components handle the UI:

import { ClerkProvider, SignInButton, SignUpButton, Show, UserButton } from '@clerk/nextjs'

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <ClerkProvider>
          <header>
            <Show when="signed-out">
              <SignInButton />
              <SignUpButton />
            </Show>
            <Show when="signed-in">
              <UserButton />
            </Show>
          </header>
          {children}
        </ClerkProvider>
      </body>
    </html>
  )
}

That's a working, secure sign-in with no custom auth code. <Show when="signed-out"> renders the sign-in and sign-up buttons, and <Show when="signed-in"> swaps in the user menu. To protect a page or API route, run the check where the data is read or mutated rather than in middleware: call await auth() in the server component or route handler and handle the signed-out case. Clerk's current guidance is to protect access as close to the resource as possible.

Building: the responsible-minimum checklist if you still choose DIY

If a hard constraint puts you in the build column, here's the floor to do it safely. None of this is optional, and none of it is the fun part.

Frequently Asked Questions

The verdict

For most teams, buy. A managed provider ships in an afternoon, hands you a security and compliance posture you'd otherwise build and audit yourself, and covers the enterprise features you'll grow into. Build when a hard constraint forces it (regulation, sovereignty, a dedicated security mandate) or when you're learning. Among managed providers, Clerk is a strong default: fast setup, broad auth methods, native B2B, and low data lock-in, with the honest caveats that enterprise pricing is custom and deep customization means working with hooks.

Clerk's free tier covers 50,000 monthly retained users (MRU), which is enough to run a real product while you evaluate the buy path yourself (Clerk Pricing). Get started free⁠, or start with the Next.js quickstart.

Every figure here is dated and linked to a primary source. Pricing, GA status, and compliance details change, so check the linked pages before you decide.

In this series

1. Build vs Buy Authentication: The Real Cost of Rolling Your Own Auth
2. Build vs Buy Authentication: The Real Cost of Rolling Your Own Auth - Part 2 (you are here)