# What Is Auth-as-a-Service? The Complete Guide - Part 2

> Part 2 of 4. Start with [What Is Auth-as-a-Service? The Complete Guide](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide.md).

# What Is Auth-as-a-Service? The Complete Guide - Part 2

When implementing authentication, engineering teams face a fundamental choice: build and operate the infrastructure themselves, or offload the burden to a managed provider. This article is the second in a four-part series on auth-as-a-service (AaaS). Building on the core concepts covered in Part 1, this part explores the managed versus self-hosted authentication landscape, analyzes the scenarios where each approach wins, and provides a detailed decision framework for the build-versus-buy debate.

## The Managed vs Self-Hosted Authentication Landscape

Auth infrastructure falls into four broad camps. The lines get fuzzy at the edges — especially because several vendors (SuperTokens, Ory, FusionAuth) ship both a managed and a self-hostable product — but the practical categorization is:

1. **Managed AaaS** — a vendor runs the identity platform; you call it over APIs and SDKs.
2. **Self-hostable platforms** — a vendor-published identity platform that you run on your own infrastructure.
3. **Open-source libraries** — code you pull into your application and configure; you operate everything.
4. **Fully custom builds** — you write the auth code yourself from primitives.

### Managed Authentication (Auth-as-a-Service)

The dominant camp. A managed AaaS takes the entire operational burden: uptime, security patches, certifications, incident response, anti-abuse tooling, and capacity.

**Pros**

- Fastest time to a production-grade login experience.
- Vendor absorbs uptime, security response, and patching.
- Compliance certifications (SOC 2, HIPAA BAA, GDPR, ISO 27001) roll through to you.
- Broad feature coverage — MFA, passkeys, social, SSO, organizations, M2M, audit logs — ships on day one.
- Vendor handles credential-stuffing defense, bot detection, and DDoS mitigation on endpoints most teams never think about.

**Cons**

- Usage-based pricing that grows with MAUs, organizations, or connections.
- User and session data live on vendor infrastructure.
- You are constrained by the vendor's feature set for genuinely unusual flows.
- Data lock-in is a legitimate concern, addressed in detail below.

**Representative providers (April 2026):** Clerk, Auth0 (Okta), Okta Customer Identity, WorkOS, Supabase Auth, Firebase Authentication, Stytch (Twilio), Descope, Frontegg, PropelAuth, Kinde, Amazon Cognito.

### Self-Hosted Authentication

Self-hosted breaks down into three subcategories, each with different economics.

#### Open-Source Libraries

Libraries run inside your application process. You pull in a package, wire it to your own database, apply the patches, and own every edge case yourself. They are the lightest-weight self-hosted option and the most code-forward: the auth logic lives in your application, not in a separate service or a vendor runtime.

Libraries win on cost and on control. They lose on security response time, feature breadth, operational ownership, and the sheer volume of tickets that drop on a small team the moment an auth edge case hits production. The open-source library landscape also churns quickly — maintainership, funding, and project direction shift often enough that betting a multi-year product roadmap on any single library carries real risk. Evaluate a library's maintenance status and security-response track record before adopting it.

#### Self-Hostable Platforms (Keycloak, SuperTokens, Ory, FusionAuth)

Platform-grade auth you operate yourself. The closest analog to an AaaS without the vendor runtime.

| Platform                                 | License              | Managed option              | Main strength                                                        | Main drawback                                                                                                                                                                                      |
| ---------------------------------------- | -------------------- | --------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Keycloak                                 | Apache 2.0 (Red Hat) | No (supported distros only) | Free, feature-rich, SAML + OIDC                                      | Operational overhead (1,250 MB base RAM + 500 MB per 100K sessions per pod per [Keycloak HA sizing docs](https://www.keycloak.org/high-availability/multi-cluster/concepts-memory-and-cpu-sizing)) |
| SuperTokens                              | Apache 2.0           | Yes (5K MAU free)           | Framework-agnostic, code-forward                                     | Narrower feature set than Auth0/Clerk                                                                                                                                                              |
| Ory (Kratos + Hydra + Keto + Oathkeeper) | Apache 2.0           | Ory Network                 | OpenID Certified OAuth 2.1 (Hydra, used by OpenAI)                   | Steep learning curve, assembly required                                                                                                                                                            |
| FusionAuth                               | Proprietary freeware | Yes (FusionAuth Cloud)      | Single-tenant self-hosting with unlimited users on Community edition | Closed-source core; enterprise features require paid tiers                                                                                                                                         |

Keycloak is the canonical reference. Red Hat's supported distributions run across versions 26.0 / 26.2 / 26.4 as of April 2026. The [Keycloak HA sizing docs](https://www.keycloak.org/high-availability/multi-cluster/concepts-memory-and-cpu-sizing) give a useful capacity heuristic: 1 vCPU handles roughly 15 logins per second, and 100,000 active sessions consume about 500 MB of RAM per pod on top of a 1,250 MB base.

#### Fully Custom Builds

Writing the authentication state machine, password hashing, session cookies, an OIDC server, MFA enrollment and challenge, and SSO from scratch.

> Custom auth is the single most commonly cited source of preventable security incidents in the OWASP Top 10:2025 A07 Authentication Failures category, which documents 36 CWEs and 1,120,673 occurrences. Timing attacks, cleartext logs, session-fixation vulnerabilities, and silent MFA bypasses all make regular appearances in post-incident write-ups. See [CloudBees' _Don't Roll Your Own Auth_](https://www.cloudbees.com/blog/why-you-shouldnt-roll-your-own-authentication), [FusionAuth's implementation-risks overview](https://fusionauth.io/articles/authentication/common-authentication-implementation-risks), and [AuthSignal on the real cost of building auth in-house](https://www.authsignal.com/blog/articles/the-real-cost-of-building-authentication-in-house).

The economics match the risk. [Beetechy](https://beetechy.com/2026/03/10/custom-vs-managed-authentication-cost/) estimates 300 hours and $45,000 for basic custom auth. [Prefactor's _Build vs Buy 2025_](https://prefactor.tech/blog/build-vs-buy-2025-authentication) puts B2B enterprise SSO at 3 to 6 developer-months and $250,000 to $500,000, with $315,000 to $850,000 per year of subsequent maintenance. [Gupta Deepak's implementation guide](https://guptadeepak.com/the-complete-guide-to-authentication-implementation-for-modern-applications/) estimates two months minimum to ship anything production-grade.

### Hybrid and BYO-Infrastructure Models

Most real-world AaaS integrations pick up one or more hybrid patterns that blur the boundary between "managed" and "self-hosted." Five are common enough to name.

1. **Webhook-based user sync.** The dominant hybrid pattern. The provider fires `user.created`, `user.updated`, `user.deleted`, `organization.created`, and `membership.created` events at a developer endpoint; the application persists a copy of the user to its own database for reporting, caching, or joins. Eventually consistent; requires retry and idempotency handling. See [Clerk's webhook-sync guide](https://clerk.com/docs/guides/development/webhooks/syncing.md).
2. **Custom database connections.** The Auth0 pattern: the provider runs customer-supplied JavaScript functions in a Node.js runtime against the customer's own database at sign-in or sign-up. Higher coupling and more brittle than webhook sync, but lets a team reuse an existing user table unchanged.
3. **Custom domain / BYO hostname.** Most providers support serving the hosted UI and auth API from a customer-owned domain. Removes hostname lock-in without moving infrastructure. See [Clerk CNAME / Custom Domains](https://clerk.com/glossary.md#cname-custom-domains-auth).
4. **Custom JWT claims and session-token customization.** Embed authorization context — organization ID, roles, feature flags, entitlements — directly in the token rather than syncing data to your own database. Clerk exposes this via [JWT Templates](https://clerk.com/docs/guides/sessions/jwt-templates.md) and [customizable session tokens](https://clerk.com/docs/guides/sessions/customize-session-tokens.md) (the default session token supports custom claims up to roughly 1.2 KB because of browser cookie-size limits).
5. **Managed + self-hosted duality.** SuperTokens and Ory ship the same codebase as both managed cloud and self-hostable distributions. You can prototype on the managed tier and migrate to self-hosted without rewriting application code.

The hybrid patterns matter for the lock-in conversation below: they are the levers a team has for reducing coupling without jumping to full self-hosting.

***

## When Managed Auth-as-a-Service Wins

For the vast majority of teams, managed AaaS is the correct default. [Auth0's _When to Build and When to Buy_](https://auth0.com/blog/when-to-build-and-when-to-buy/) estimates that fewer than 5% of engineering teams should build authentication from scratch. The reasoning breaks down into six specific advantages.

### Development Speed and Time-to-Market

Basic custom authentication runs about 300 hours of engineering effort and $45,000 of loaded cost per [Beetechy's _Custom vs Managed Auth Cost_](https://beetechy.com/2026/03/10/custom-vs-managed-authentication-cost/). Adding B2B enterprise SSO pushes the timeline to 3 to 6 developer-months and $250,000 to $500,000 per [Prefactor's _Build vs Buy 2025_](https://prefactor.tech/blog/build-vs-buy-2025-authentication). Adding SCIM alone is another 7 to 8 weeks. Integrating a managed provider is typically measured in hours to days.

Clerk's Next.js 16 quickstart — `<ClerkProvider>` in the root layout and `proxy.ts` at the project root — delivers a working auth experience in minutes rather than weeks. The Core 3 SDK (shipped March 3, 2026) adds **keyless mode** as a local-development convenience: a new project auto-provisions a temporary sandbox instance without any API-key configuration, so a developer can run `pnpm dev` and sign in immediately. Production deployments still use standard Publishable Keys (`pk_live_*`) and Secret Keys (`sk_live_*`); keyless mode does not ship user data to production tenants on its own.

The feature-breadth argument compounds the time-to-market advantage. A managed provider ships MFA, passkeys, social providers, SSO, organizations, and machine authentication on day one. Each of those capabilities is roughly a week to a quarter of custom engineering time; bundling them is the point of the category.

### Security Expertise and Vulnerability Response

Homegrown auth fails in patterns that are well documented but rarely anticipated. [CloudBees on timing attacks](https://www.cloudbees.com/blog/why-you-shouldnt-roll-your-own-authentication) describes a Rails authentication bug where valid email lookups took roughly 130 ms and invalid ones returned faster, letting attackers enumerate user accounts. Cleartext logs of password hashes, session-fixation vulnerabilities, weak MFA fallbacks, and credential-stuffing susceptibility all appear in [OWASP Top 10:2025 A07](https://owasp.org/Top10/2025/A07_2025-Authentication_Failures/) with 36 CWEs and 1,120,673 recorded occurrences.

Well-run AaaS vendors run dedicated security teams, publish [vulnerability disclosure policies](https://clerk.com/docs/security/vulnerability-disclosure-policy.md), operate bug bounty programs, and ship patches faster than most internal teams can triage a CVE. MFA blocks over 99.9% of account compromise attacks per [Microsoft's 2019 security blog](https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/) — the number is vendor-sourced and widely cited, though not peer-reviewed. Passkeys sign users in successfully 98% of the time versus 32% for passwords per [Microsoft's December 2024 passkeys UX analysis](https://www.microsoft.com/en-us/security/blog/2024/12/12/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/), and 53% of consumers have enabled passkeys on at least one account per the [FIDO Alliance 2024 World Password Day report](https://fidoalliance.org/content-ebook-consumer-password-and-passkey-trends-wpd-2024/).

### Compliance and Certifications (SOC 2, HIPAA, GDPR, ISO 27001)

Compliance is the gate for enterprise procurement and for any app that handles regulated data. Building the controls, audit trails, and evidence to pass an independent audit is 12 to 24 months of focused work per [FusionAuth's build-vs-buy guide](https://fusionauth.io/buildvsbuy). A managed provider inherits them to your application with a shared-responsibility model.

- **[SOC 2](https://clerk.com/glossary.md#soc-2) Type II** — the enterprise procurement gate under the AICPA Trust Services Criteria (Security is required; Availability, Confidentiality, Processing Integrity, and Privacy are optional). Typical observation periods run 6 to 12 months. Clerk, Auth0, WorkOS, Supabase, Stytch, and Descope all hold Type II reports.
- **[HIPAA](https://clerk.com/glossary.md#health-insurance-portability-accountability-act-hipaa)** — required for healthcare protected health information (PHI). The Business Associate Agreement (BAA) is the critical artifact. The 2026 HIPAA Security Rule update (currently an NPRM) is poised to mandate MFA for all ePHI access. Clerk's Enterprise tier includes a BAA.
- **GDPR** — mandatory for EU resident data. Article 32 covers security requirements; Article 20 enshrines the right to data portability.
- **ISO/IEC 27001:2022** — preferred in EMEA and APAC enterprise deals. Clerk is compliant with the standard but not yet certified; certification is on the 2026 roadmap.
- **[CCPA/CPRA](https://clerk.com/glossary.md#california-consumer-privacy-act-ccpa)** — California state privacy law. Login credentials are explicitly "sensitive personal information" under the CPRA amendments.
- **FAPI 1 Advanced and FAPI 2.0** — financial-grade API security required for open banking. Auth0's Highly Regulated Identity (HRI) product is certified against [FAPI 1 Advanced (Okta | CIC – Highly Regulated Identity 1.0, September 12, 2023)](https://openid.net/certification/certified-fapi1-adv-openid-providers-profiles/) and [FAPI 2.0 Security Profile Final (Okta | Auth0 – Highly Regulated Identity – 202527, July 9, 2025)](https://openid.net/certification/certified-fapi-2-0-op-security-profile-final-message-signing-final/) via the OpenID Foundation registry. Auth0 also publishes [configuration guidance for FAPI conformance testing](https://auth0.com/docs/get-started/applications/configure-fapi-compliance/configure-auth0-to-pass-openid-fapi-certification-tests). Clerk does not support the financial-grade FAPI profile (Clerk's internal documentation uses "FAPI" to abbreviate "Frontend API," an unrelated concept).
- **FedRAMP** — US federal procurement. Okta for Government holds a High Authorization to Operate.

### Scaling, Availability, and Global Reliability

Running authentication at scale means running it when everything else breaks. Clerk's [public status page](https://status.clerk.com/) reports 99.96% observed uptime from January through April 2026; Enterprise contracts carry a 99.99% SLA. Stytch advertises a 99.999% SLA. Auth0's typical tier is 99.9%; Okta Enterprise is 99.99%.

Managed providers shoulder credential-stuffing defense, bot mitigation, WAF tuning, and capacity planning for sign-in spikes that can hit 10x normal traffic during marketing launches or Black Friday events. The [Verizon 2025 DBIR supplemental research](https://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/) reports that a median 19% of authentication attempts in the surveyed corpus were credential stuffing (peaking at 44% on a single day for individual organizations, and hitting 25% median at enterprise scale). The capacity math for self-hosting at comparable scale is brutal: per the [Keycloak HA sizing docs](https://www.keycloak.org/high-availability/multi-cluster/concepts-memory-and-cpu-sizing), 1 vCPU serves roughly 15 logins per second and 100,000 active sessions consume 500 MB of RAM per pod.

### Feature Breadth Out of the Box (MFA, SSO, Passkeys, Social, Organizations)

The canonical feature bundle a managed provider ships on day one:

- Passwords with modern hashing, email OTP, SMS OTP, magic links.
- Passkeys (WebAuthn/FIDO2) with biometric and hardware-key support.
- Social sign-in for 20+ providers.
- Enterprise SSO (SAML 2.0, OIDC) and SCIM 2.0 directory sync.
- Organizations with memberships, roles, and invitations.
- Machine authentication (M2M tokens, API keys, increasingly MCP).
- Audit logs, webhooks, custom session-token claims.
- Account recovery, account linking, account deletion.

Clerk ships 25+ social connections, EASIE enterprise SSO (a multi-tenant OpenID alternative to SAML launched November 20, 2024), SAML, OIDC, Web3 wallets, passkeys, TOTP, SMS and email MFA, passkeys-as-second-factor, hardware security keys, M2M tokens, API keys, organizations with role sets, Directory Sync (SCIM 2.0), and an MCP server out of the box.

### Total Cost of Ownership Over Time

TCO math tilts the same direction as the speed math. Representative list prices, as of April 2026:

- **Custom build:** $45,000 initial + $315,000 to $850,000 per year in maintenance per Prefactor, plus the opportunity cost of the engineering team.
- **Keycloak self-hosted:** $200 to $700 per month in infrastructure for moderate scale per [SkyCloak's comparison](https://skycloak.io/blog/keycloak-vs-auth0-comparison-guide/) + $100,000 to $200,000 per year in engineering time per [SuperTokens' cheapest-auth-alternatives analysis](https://supertokens.com/blog/cheapest-auth-alternatives).
- **Auth0 at 50K MAUs:** \~$3,500 per month on the self-serve B2C Essentials plan per [Auth0's pricing page](https://auth0.com/pricing). Auth0's consumer pricing climbs in discrete MAU bands and its Professional plan tops out at 20,000 MAUs, so crossing into the tens of thousands forces the Essentials stepped tier or an Enterprise contract — the steep tier jumps Auth0 is known for.
- **Clerk at 50K MRUs:** \~$0 to $25 per month per [Clerk's pricing page](https://clerk.com/pricing). The free Hobby plan includes 50,000 monthly retained users (raised from 10,000 in the [February 5, 2026 restructure](https://clerk.com/changelog/2026-02-05-new-plans-more-value.md)) and the Pro plan adds a $25/month base over the same allotment; metered overage begins only above 50,000. Clerk also bills _retained_ users — a user who never returns after the day they sign up is not counted — so a 50,000-retained-user workload typically sits inside the free tier.
- **Supabase Pro:** $25 per month up to 100K MAUs per [Supabase's pricing page](https://supabase.com/pricing) — the cheapest credible managed option among the broad-feature providers, with the tradeoff of tight coupling to the Supabase ecosystem.

The right vendor is the one whose feature coverage and pricing curve match your projected 3-year growth, not the cheapest sticker price today.

***

## When Self-Hosted Authentication Makes Sense

Self-hosted wins in a narrow set of scenarios. Most teams do not live in those scenarios. Four cases are defensible.

### Strict Data-Residency or Air-Gapped Environments

Defense contractors, classified environments, regulated financial systems that require single-tenant deployment, and some government and healthcare workloads cannot move auth data into a multi-tenant SaaS. FusionAuth and Keycloak are the primary options because most commercial managed vendors — notably Okta and Auth0 — [stopped offering true on-premises deployments](https://fusionauth.io/blog/auth0-and-fusionauth-a-tale-of-two-solutions) around 2021. [FusionAuth's _When to Self-Host_](https://fusionauth.io/blog/when-to-self-host) enumerates the regulatory drivers.

### Highly Unusual Auth Flows No Vendor Supports

Rare. Most providers support OAuth 2.0, OpenID Connect, SAML 2.0, passwordless variants, M2M, the device-code flow, and Client-Initiated Backchannel Authentication (CIBA). A flow that no commercial vendor supports probably either (a) is not actually unusual and a team overestimates their weirdness, or (b) is niche enough that the engineering cost of building it is rarely worth the deliverable. Scope carefully before committing to a self-hosted build on this basis.

### Very Low-Volume Internal Tools

For internal tools serving under 100 users, the math inverts: most managed providers' minimums — setup time, minimum pricing tiers, mandatory Enterprise upgrades for SSO — can exceed the value of the tool itself. A Keycloak instance, Authentik, or a lightweight open-source auth library backed by a small database is often simpler. The [hyperknot auth-provider comparison](https://blog.hyperknot.com/p/comparing-auth-providers) covers the low-volume case well.

### Cost at Extreme Scale (With Caveats)

Past 1 million monthly active users, the per-MAU economics tilt toward self-hosted on paper. Keycloak infrastructure runs $200 to $700 per month across most user-volume bands versus Auth0 at $15,000 per month at 500K MAUs per SkyCloak's analysis.

The paper savings assume a dedicated SRE/security team already exists. In practice, many companies stay on managed auth at extreme scale because the marginal cost of a breach — [IBM's 2025 report](https://www.ibm.com/reports/data-breach) puts the global average at $4.44 million — is larger than the marginal cost of the SaaS bill. The scale argument is also weaker than it looks because the pricing curves for Clerk, WorkOS (AuthKit's 1M MAU free tier), and Stytch are all less aggressive than Auth0's, so "Auth0 at 500K MAUs" is the comparison that actually justifies self-hosting, not "AaaS category at 500K MAUs."

***

## Build vs Buy Authentication: A Decision Framework

The decision framework distills to a questionnaire, a TCO comparison, and a matrix. Each is designed to be directly consumable by an AI agent advising a team.

### Questions to Ask Before Building In-House

A 10-question checklist. The "if yes → buy" / "if no → consider build" heuristic fits most answers; the exceptions are specifically called out.

1. **Do we have a dedicated security team?** If no → buy. Most teams answer no.
2. **Is authentication a differentiator in our product?** If no → buy. Almost always no.
3. **Do we need SOC 2, HIPAA, or GDPR compliance within 12 months?** If yes → buy. Those certifications are 12–24 months DIY.
4. **Do we need enterprise SSO (SAML, SCIM) to win B2B deals?** If yes → buy. SSO alone is 3–6 months to build; SCIM adds 7–8 weeks.
5. **Are we past 100,000 users?** If yes → buy. DIY compliance and security response at scale is brutal.
6. **Is our user base in a regulated air-gapped environment?** If yes → self-host on FusionAuth or Keycloak.
7. **Do we have 12+ months of runway dedicated to auth specifically?** If no → buy.
8. **Can we absorb a TCO of $200K–$500K per year in maintenance?** If no → buy.
9. **Do we need MFA, passkeys, social login, and organizations now?** If yes → buy. Feature breadth compounds build timelines.
10. **Is vendor lock-in a deal-breaker?** Addressed in the lock-in section below. The short answer: buy from a provider with strong data portability rather than abandoning the category.

Sources: [Auth0 on build vs buy](https://auth0.com/blog/when-to-build-and-when-to-buy/), [Stytch on build vs buy](https://stytch.com/blog/build-vs-buy/), [FusionAuth on build vs buy](https://fusionauth.io/buildvsbuy), [Prefactor's 2025 analysis](https://prefactor.tech/blog/build-vs-buy-2025-authentication), [Authgear on build vs buy](https://www.authgear.com/post/authentication-as-a-service).

### Total Cost of Ownership Comparison

Representative 1-year and 3-year totals. Provider list prices; real pricing varies with features, connections, and negotiation.

| Approach                                   | Year 1 Cost          | 3-Year Cost | Engineering Time                |
| ------------------------------------------ | -------------------- | ----------- | ------------------------------- |
| Custom build (basic)                       | \~$45K + team salary | \~$200K+    | 300+ hours upfront, ongoing     |
| Custom build (enterprise-grade SSO + SCIM) | $250K–$500K          | $800K–$1.5M | 3–6 months + annual maintenance |
| Keycloak self-hosted (50K MAUs)            | $100K–$200K          | $300K–$600K | 0.25–1 FTE ongoing              |
| Auth0 Essentials (50K MAUs)                | \~$42K               | \~$126K     | Weeks to integrate              |
| Clerk (50K MAUs)                           | \~$0–$300            | \~$0–$900   | Hours to days to integrate      |

Sources: [Beetechy](https://beetechy.com/2026/03/10/custom-vs-managed-authentication-cost/), [Prefactor](https://prefactor.tech/blog/build-vs-buy-2025-authentication), [Clerk pricing](https://clerk.com/pricing), [Auth0 pricing](https://auth0.com/pricing), [SkyCloak](https://skycloak.io/blog/keycloak-vs-auth0-comparison-guide/), [SuperTokens' cheapest-auth analysis](https://supertokens.com/blog/cheapest-auth-alternatives).

> Pricing figures in this section are list prices as of April 2026 and exclude negotiated discounts. Managed-provider pricing — Clerk's and Auth0's especially — changes frequently; verify the current numbers on each provider's own pricing page before relying on them. At 50,000 users Clerk's free tier generally covers the workload, so its entry reflects the Pro base rather than per-user overage.

### Decision Matrix Checklist

Read each row as a recommendation for the matching criterion: a green **Yes** check marks a recommended fit, an orange **Acceptable** marker marks a workable but non-ideal fit, and a red **No** cross marks a not-recommended fit.

| Criterion                                       | Managed AaaS | Self-Hosted |   Custom   |
| ----------------------------------------------- | :----------: | :---------: | :--------: |
| Need SOC 2 / HIPAA / GDPR within 12 months      |      Yes     |  Acceptable |     No     |
| Need enterprise SSO (SAML, SCIM)                |      Yes     |  Acceptable |     No     |
| Scale >100K MAUs, no dedicated security team    |      Yes     |      No     |     No     |
| Scale >1M MAUs with dedicated SRE/security team |      Yes     |     Yes     |     No     |
| Air-gapped / strict data residency              |      No      |     Yes     | Acceptable |
| Very low-volume internal tool (<100 users)     |  Acceptable  |     Yes     | Acceptable |
| Fastest possible time-to-market                 |      Yes     |      No     |     No     |
| Constrained TCO budget                          |      Yes     |  Acceptable |     No     |
| Rare, unsupported auth flow                     |      No      |     Yes     |     Yes    |
| Standard web or mobile application              |      Yes     |  Acceptable |     No     |

**For most teams: Managed AaaS.**

***

For the vast majority of teams, the speed, security, and compliance benefits of managed auth-as-a-service far outweigh the costs of building in-house. However, choosing a managed provider introduces concerns about vendor lock-in. In Part 3, we examine the realities of authentication vendor lock-in, detail what true data portability looks like, and provide an overview of the leading AaaS providers in the market.

## Frequently Asked Questions

## FAQ

### Is self-hosting authentication cheaper than managed auth?

At extreme scale (over 1 million monthly active users), self-hosting can appear cheaper on paper. However, this assumes a dedicated SRE and security team is already in place. For most applications, the total cost of ownership (TCO) of managed auth is significantly lower when factoring in engineering time, maintenance, and the cost of potential security incidents.

### How long does it take to build enterprise authentication from scratch?

Basic custom authentication typically requires around 300 hours of engineering effort. Adding enterprise features like SAML SSO pushes the timeline to 3 to 6 developer-months, and SCIM directory sync adds another 7 to 8 weeks. In contrast, integrating a managed provider is usually measured in hours to days.

### When does self-hosting authentication make sense?

Self-hosting is generally recommended only for strict data-residency or air-gapped environments (like defense or regulated finance), highly unusual auth flows that no vendor supports, or very low-volume internal tools where managed provider minimums exceed the tool's value.

## In this series

1. [What Is Auth-as-a-Service? The Complete Guide](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide.md)
2. **What Is Auth-as-a-Service? The Complete Guide - Part 2** (you are here)
3. [What Is Auth-as-a-Service? The Complete Guide - Part 3](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide-3.md)
4. [What Is Auth-as-a-Service? The Complete Guide - Part 4](https://clerk.com/articles/what-is-auth-as-a-service-the-complete-guide-4.md)
