Self-Hosted Authentication: Why Run Your Own Identity Provider

Why authentication is becoming a strategic decision

For years, the default answer to "how do we add login to our app?" was simple: drop in a managed identity provider (IdP). Auth0, Okta, Firebase Auth, AWS Cognito, Microsoft Entra ID (formerly Azure AD B2C) — they all promised authentication-as-a-service in a few lines of code. For early-stage products, that promise held.

But as products mature, the trade-offs of managed auth SaaS become harder to ignore. Auth0's per-user pricing has repeatedly made headlines after acquisition-related changes; Okta's per-MAU billing compounds quickly for B2C apps; Firebase Auth ties you to the Google Cloud ecosystem more tightly each year. At the same time, GDPR, HIPAA, and SOC 2 auditors increasingly scrutinize where identity data flows during the authentication handshake itself — not just where it is stored.

The result is a quiet but steady trend: engineering teams that originally picked managed auth for speed-to-market are now migrating to self-hosted identity providers. This article breaks down why, what the alternatives look like, and how to choose between them.

Who should care about authentication strategy

Authentication decisions tend to fly under the radar until a specific moment forces them onto the roadmap. In practice, that moment looks like one of these:

• The MAU bill crosses a pain threshold. A consumer product crosses 50k–100k monthly active users and the per-MAU line item on the IdP invoice starts dwarfing the rest of the infrastructure bill.
• A compliance audit asks uncomfortable questions. The SOC 2 or GDPR auditor wants to know exactly which subprocessors see user identity tokens, where they are located, and under what legal basis.
• A vendor outage takes sign-in down with it. The auth provider has a multi-hour incident — and every product that depends on it for login is effectively offline.
• A new integration requirement appears. A enterprise customer asks for SAML SSO, SCIM provisioning, or a custom MFA policy that the managed plan doesn't support without a tier upgrade.

If any of these resonates, it's worth revisiting the auth stack on purpose rather than reacting under pressure.

A quick refresher: OAuth 2.0 and delegated authentication

Delegated authentication is the model where a user lets one application verify their identity through another service, without sharing a password. OAuth 2.0 is the open protocol that implements this model and has become the de-facto standard across the web.

When a user clicks "Sign in with Google", this is roughly what happens:

1. The application redirects the user to Google.
2. The user signs in there and confirms consent.
3. Google returns an access token to the application — a short-lived "pass" that proves the user's identity and the application's rights.
4. The application uses the token to retrieve account data (email, name) and opens a session of its own.

The user doesn't have to create and remember yet another password, and the application doesn't have to verify credentials itself — that's the job of a trusted IdP. With a managed SaaS IdP, that trusted party is a third-party company. With a self-hosted IdP, it's a system you operate.

This distinction matters for everything that follows: cost, control, vendor dependence, and data residency all flow from who runs the IdP.

The hidden costs of managed auth SaaS

The convenience of "login in 5 minutes" obscures a set of structural costs that surface only after a product scales. The biggest ones:

• Pricing scales with users, not value. Most managed IdPs charge per monthly active user. Your auth bill grows linearly with product success, even though the actual compute cost of verifying a password is essentially flat. For B2C products, this is often the single largest variable SaaS line item.
• Vendor lock-in deepens silently. Custom claims, rules, actions, tenant configuration, branding — all of it lives in the vendor's proprietary console. Migrating away means reverse-engineering years of configuration.
• Data residency is non-trivial. Even when the IdP stores data in your region, the token exchange during sign-in may route through region-agnostic endpoints. Demonstrating this to a GDPR or HIPAA auditor is harder than it sounds.
• Outages are out of your hands. When the IdP goes down, every product that uses it for login is functionally down too. You inherit the vendor's SLA and incident response — there is no way to fail over.
• Plan-tier gating. Features that enterprises increasingly expect — SAML, SCIM, adaptive MFA, custom domains, step-up authentication — are often locked behind enterprise tiers priced for Fortune 500 budgets.

None of this means managed SaaS is always wrong. It means the decision deserves to be made deliberately, not by default.

Three strategies, not mutually exclusive

There are three realistic ways to run authentication in a modern product:

1. Build your own login, registration, password reset, and session logic inside the product itself.
2. Self-host an Identity Provider — deploy a mature IdP like Keycloak, Authentik, or Zitadel on your own infrastructure.
3. Stay with managed SaaS — Auth0, Okta, Firebase Auth, AWS Cognito, Microsoft Entra ID, or similar.

In mature setups these are usually combined: a self-hosted Keycloak sits at the center as the authoritative IdP, while external providers (Google, Microsoft, Apple, GitHub, an enterprise customer's SAML IdP) are wired in as federated sources. Let's walk through each option on its own.

Option 1. Build your own

The team writes registration, login, password reset, and session management directly into the product — on top of a framework (Laravel, Django, Spring Security, NestJS) or entirely from scratch.

What you have to account for:

• secure credential storage using proven password hashing schemes;
• email verification flows;
• user notification system for security events;
• phone number verification through an SMS gateway or aggregator (Twilio, MessageBird, Vonage, etc.);
• password reset with short-lived, single-use tokens;
• brute-force and credential-stuffing protection (rate limiting, CAPTCHA, lockout policies);
• session management: httponly + secure cookies, short-lived JWTs with refresh tokens stored in a DB;
• two-factor authentication (TOTP, SMS, push, WebAuthn);
• an ever-growing list of attack vectors (CSRF, session fixation, JWT confusion, timing attacks, and more);
• login and anomaly logging.

Advantages:

• Maximum control. No external dependencies, all data stays inside the product.
• Minimal infrastructural footprint. No separate service to operate, no OIDC/SAML expertise required, no user-base synchronization.
• No license fees. Only SMS and hosting costs.
• Tight product integration. The whole implementation lives in your codebase.

Disadvantages:

• High load on the team. Securely implementing authentication is non-trivial; mistakes here are the most expensive kind of bug.
• High development cost. A production-grade auth subsystem takes months and carries serious design, engineering, and security review overhead.
• Reinventing what mature IdPs ship out of the box: SSO, MFA, federation, audit logs, adaptive policies.
• Slow to extend. Every new requirement (WebAuthn, SAML for an enterprise customer, SCIM provisioning) becomes a separate project.
• You alone own the vulnerabilities. No community, no regular security patches from a vendor. Hiring engineers who genuinely specialize in authentication security is hard and expensive.

Building your own is justifiable for small products with a simple user model and a constrained team, where a full IdP feels like overkill. The more integrations, services, and security requirements you accumulate, the more expensive this path becomes relative to adopting a proven solution.

Option 2. Self-host an Identity Provider: Keycloak and friends

A mature Identity & Access Management system you deploy on your own infrastructure — your data center, a private cloud, or a public cloud (AWS, Azure, GCP, Hetzner, DigitalOcean). The deployment model depends on your security, compliance, and budget requirements — we covered that trade-off in detail in a separate article on on-premise vs. cloud deployments.

These are usually battle-tested open-source projects with active community support. SSO across many applications, user management, modern security standards, and a broad set of integrations come in the box.

Popular open-source options

• Keycloak — the most mature product, the de-facto enterprise standard. Supports OIDC, SAML 2.0, OAuth 2.0, Kerberos, LDAP/AD, ships with a user account console, MFA, social login, and rich password policies. Used by a large number of enterprises and financial institutions.
• Authentik — a newer Python/Go alternative with visual authentication flow builder, a clean API, and a pleasant UI.
• Zitadel — cloud-native architecture with multi-tenancy out of the box, a strong fit for SaaS products.
• Casdoor — a lightweight Go option with broad social-login provider support.
• Authelia — a simple single-sign-on solution for small corporate or home environments, operating as a reverse-proxy filter.

Of these, Keycloak is the most universal, stable, and time-tested option.

Key capabilities

• Single Sign-On (SSO) across all corporate applications — the user signs in once and is not prompted again across connected services.
• User directory federation — connect external IdPs (Google, Microsoft, Apple, GitHub, an enterprise customer's SAML IdP, corporate LDAP/AD) in one place.
• Multi-factor authentication — built-in support for TOTP authenticator apps, mobile biometrics, WebAuthn, SMS, and hardware keys.
• Users and groups management — delegation, role-based access control (RBAC), attributes, organizations/tenants. User bases for different products can be isolated while roles and permissions stay flexible.
• OAuth 2.0 / OIDC provider — your product can act as an IdP for third-party services, so other companies can sign in through your system.
• Audit and logging — who signed in, when, from where, and what they did.
• Adaptive access policies — restrictions by IP, time, device, or risk score.

Advantages

• Full control over data. All identity data lives on your infrastructure, in your database.
• Enterprise-grade functionality out of the box — the kind that would take months of in-house development and significant budget.
• Active community and regular security updates from the project's maintainers.
• Modest deployment and maintenance costs. A broad pool of engineers has experience with these systems, and documentation is plentiful.
• Covers ~90% of real-world requirements out of the box. Custom modules can be written for the remaining 10%.
• External login providers are plug-and-play. Adding Google, Microsoft, Apple, or GitHub sign-in takes hours, not days.

Disadvantages

• DevOps expertise is required. Deployment, configuration, upgrades, backups, and monitoring fall on your team.
• A learning curve for configuration. Understanding OIDC flows, claim mappings, client scopes, and policies takes time — though these are widely documented open standards.
• Upgrades and backups are your responsibility — that risk lives with you.

A self-hosted IdP is the default choice for mid-size and large companies, for SaaS products with multiple services, and for anyone who needs integration with a corporate directory (AD/LDAP) or enterprise SSO.

Save months of building your own system

Reach out and we will design a solution that fits your business. We help deploy an authorization system, migrate existing services, and configure data storage to meet your compliance and residency requirements.

Get a plan for your project.

Option 3. Managed SaaS authentication

External services that take on user authentication and return a verified identity to your product. Technically equivalent to "Sign in with Google" — except you're the customer paying for reliability, customization, and support.

Main providers

• Auth0 (owned by Okta) — the most developer-friendly, with rich extensibility via Actions and Rules. Pricing scales per MAU and becomes painful at scale.
• Okta — the enterprise standard, with deep workforce-identity roots. Strong SSO, lifecycle management, and compliance certifications; pricing reflects the enterprise positioning.
• Firebase Auth — tightly integrated with the Google Cloud ecosystem. Free at low volume, but locks you into Firebase's data model and operational model.
• AWS Cognito — priced aggressively and bundled with AWS credits, but with a notoriously rough developer experience and limited customization.
• Microsoft Entra ID (Azure AD B2C) — the natural fit if you're already in the Microsoft ecosystem or serving enterprise customers with existing Entra tenants.
• Clerk, Stytch, Supabase Auth, Ory — newer entrants, each with a distinct philosophy and pricing model.

Advantages

• Fast integration. A few days reading docs and wiring up SDKs instead of weeks operating an IdP.
• No infrastructure burden. Nothing to host, upgrade, or back up.
• Polished UX. Hosted login pages, localization, and adaptive MFA without custom work.
• Compliance certifications — the vendor maintains SOC 2, ISO 27001, and (depending on tier) HIPAA attestations you can inherit.

Disadvantages

• Vendor dependence. If Auth0 or Okta has an outage, your users cannot sign in. A fallback strategy is essential.
• Commercial terms. Most providers charge per user or per request; at scale this becomes a significant budget line.
• Limited customization. You don't control password policies, token formats, session lifetimes, or claim shapes beyond what the vendor exposes.
• Federated identity fragmentation. Each provider has its own user identifier; without a unifying layer (such as Keycloak in front of them), account linking becomes a problem.
• Limited access to user data. All credentials live with the provider. Building features that depend on direct access to authentication state requires additional engineering.

A pure managed-SaaS setup is convenient for B2C products with large public audiences where social login has historically been the primary sign-up path. In B2B and enterprise segments, it's rarely sufficient on its own — you almost always end up needing your own user directory and corporate policy enforcement eventually.

Comparison

Which approach to choose

In most mature setups the answer is hybrid: a self-hosted Keycloak as the central IdP, with Google, Microsoft, Apple, GitHub, and enterprise SAML providers wired in as federated sources. That gives you:

• a single user directory under your control;
• out-of-the-box SSO across all your services and microservices;
• a single integration point for any external IdP, without re-engineering product code;
• predictable infrastructure costs that don't scale per user.

For B2C products with a mass audience, a combination of "your own email/password form + social-login buttons federated through Keycloak" is usually enough. For B2B / enterprise, Keycloak becomes the integration hub for corporate directories (Active Directory, Entra ID, Google Workspace), enterprise SAML IdPs, and (where regulation requires it) sector-specific identity schemes.

For a small product without integration ambitions, the realistic options are either a minimal DIY implementation with SMS verification, or a lighter self-hosted IdP like Authentik or Zitadel.

Regardless of the choice, three principles remain constant:

1. Run on infrastructure you control — your own data center or a cloud with a contract that names you as the data controller.
2. Know where identity data flows during the authentication handshake, not just where it's stored — this is what auditors actually ask.
3. Back up and rehearse recovery. Losing the IdP database means paralyzing the entire company.

Conclusion

The shift toward self-hosted identity isn't a single-event reaction the way regulatory changes are — it's a steady, structural trend driven by the economics of per-user SaaS billing, growing data-residency obligations under GDPR and HIPAA, and the simple reality that no vendor's SLA matches the cost of your product being unreachable.

The good news is that the technical work itself is well-trodden territory. Mature open-source IdPs exist, the migration paths from managed SaaS are proven, and the typical timeline runs from a couple of weeks to a couple of months depending on product complexity. The main thing is to make the decision deliberately — before a pricing update, an audit, or an outage makes it under pressure — and to treat authentication as the strategic piece of infrastructure it actually is, not a checkbox to forget about after the initial "Sign in with…" integration.