Most people arrive at open source authentication to avoid a bill, and the bill they avoid is rarely the bill they end up paying. The licence cost goes to zero on day one. The cost that replaces it is an on-call rotation for a service that, when it is down, means nobody can log in to anything you sell.
That is the distinguishing property of an identity provider and the reason it deserves a different operational standard from the rest of your stack. A degraded search service is a bad afternoon. A degraded IdP is a full outage with a support queue attached, because every product surface you own sits behind it, including the admin console your own team would use to fix things.
There is a second cost that is harder to see at evaluation time: the open core boundary. Every project on this page is free to download and most of them are genuinely open source, but several reserve the exact features an established company needs. Fine-grained admin roles. Audit log export. A supported high availability topology. SAML in some cases. You do not discover where the line falls by reading the homepage, you discover it in month seven when your first enterprise customer asks for something and the answer is a sales call.
And there is a third, which is the one that actually wakes people up. A CVE lands in an authentication component on a Friday afternoon. With a vendor, someone else patches the fleet and you read about it Monday. Self-hosted, you are the vendor. You need to know your version, know whether you are affected, know how to upgrade without invalidating every live session, and have someone who can do all three inside a weekend.
Key takeaways
- Licence cost going to zero moves the cost, it does not remove it. The replacement is upgrade work, HA design and a patching rotation on a service whose downtime is a total outage.
- The open core boundary is the decision, not the licence badge. Check specifically where audit log export, fine-grained admin roles, SAML and supported HA topologies sit before you commit.
- Keycloak, Ory, Authentik, Zitadel, SuperTokens and Logto are deployable services. Better Auth and Auth.js are libraries that run inside your application and have no vendor and no bill at all.
- Upgrade path matters more than feature list. A project that changes its user schema or its admin API between majors will cost you more over three years than any missing feature.
Where the open core boundary actually falls
“Open source” in identity covers four genuinely different arrangements, and conflating them is how teams end up surprised.
Fully permissive, single edition. The project is one codebase under a permissive licence, and what you download is what exists. Keycloak and Ory are the clearest examples. There is no feature you can unlock with money, only support you can buy. The tradeoff is that when something is missing it stays missing until someone builds it.
Open core with a commercial edition. A permissive or copyleft core plus an enterprise build gated behind a licence. SuperTokens, Authentik and Logto all sit here in some form. The core is real and usable, and the gated features cluster in a predictable place: multi-tenancy at scale, advanced admin roles, compliance reporting, support SLAs, and occasionally the enterprise protocols.
Source available, free to run. The code is readable and you can self-host at no cost, but the licence is not OSI-approved and redistribution or embedding is constrained. FusionAuth belongs in this group rather than the first two, and it matters if your legal team defines open source as OSI-approved or if you intend to ship the thing inside a product you distribute.
Library, not service. Better Auth and Auth.js are code you import. There is no separate process, no admin console, no vendor. You get exactly the flexibility of writing it yourself with most of the tedious parts already written, and you own every operational consequence.
The practical filter is not which licence label a project carries. It is this: write down the five things your business will need from auth in eighteen months, then find each one in the specific edition you plan to run. Enterprise SSO, SCIM provisioning, audit export, admin delegation and per-tenant configuration are the five that most often turn out to be on the far side of a boundary.
Needs first-hand data: For each shortlisted project, deploy the free edition and attempt the five things above end to end. Record which ones are impossible, which are possible but undocumented, and which require the commercial build. That table is the real comparison, and no vendor page will give it to you.
The upgrade is the product decision
Feature lists get compared. Upgrade paths get discovered. Over three years the upgrade path is the larger number.
An identity provider holds state that cannot be casually rebuilt: user records, password hashes, MFA enrolments, consent grants, refresh tokens, client registrations, per-tenant configuration. A major version bump touches the schema holding that state, and you cannot roll back once the migration has run without restoring a database snapshot, which means losing every login and every token issued since.
Four things to check before you adopt anything here.
Does a major upgrade require downtime? Some projects support running two versions against the same database during a rolling upgrade, some emphatically do not. If they do not, you need a maintenance window during which login is unavailable, and that window has to be negotiated with every team that depends on you.
Do sessions survive it? Some upgrades invalidate live sessions, either because the session store format changed or because the signing keys are regenerated. An upgrade that logs out every active user is not a maintenance event, it is an incident with a changelog.
How long is a version supported? A project that ships a major release every few months with a short support window means you are doing a significant upgrade continuously, forever. That is a standing tax, and it is invisible when you are evaluating.
Does the admin API change shape? If you automate tenant creation, user import or client registration, a breaking admin API means your automation breaks too, on the same day, usually unnoticed until a customer self-serve flow fails.
High availability is a data problem, not a replica count
Running three replicas of an IdP behind a load balancer is not high availability, it is three ways to fail at once. What actually determines availability is where the state lives and how it behaves under partition.
The database. Every project here keeps users, credentials and configuration in a relational database, so your identity availability is bounded by your database availability. If that database has a single writer, so does your IdP. Failover time for the database is failover time for login.
The session or token store. Some designs keep sessions in the same relational database, some in a distributed cache, some issue stateless tokens and keep only a revocation list. This choice governs both your scaling ceiling and your revocation semantics, and it is covered in depth in session management libraries.
The signing keys. Every replica must agree on the current signing key, or a token issued by one node fails validation at another. Key material shared through a database, a secret manager or an init container is a dependency you now have on the login path.
Cache coherence between nodes. Realm or tenant configuration is usually cached in memory for performance. When you change a setting, the other nodes need to know. Projects solve this with a clustering layer, a pub/sub channel or a short TTL, and each of those is a failure mode: a split cluster where half your nodes have the old client secret is a genuinely confusing outage.
The honest question to ask is what you are protecting against. A single well-backed-up node that restarts in ninety seconds is a defensible design for a lot of companies. A multi-region active-active identity plane is a large project, and most teams that start one should have bought instead. Self-hosted identity providers walks through the operational design in detail.
Who patches it when a CVE lands on a Friday
This is the question that separates teams who should self-host from teams who should not, and it has a concrete answer rather than a philosophical one.
Do you know your version? Not “we run Keycloak”, but the exact version of the IdP and of its runtime, in every environment, findable in under a minute. If that requires a person to SSH somewhere, your response time already starts in hours.
Are you subscribed to the right advisory feed? Identity CVEs often land in a dependency rather than the project itself: a JOSE library, an XML parser used by the SAML path, a template engine in the admin console. Watching the project’s release notes alone misses the ones that matter most.
Can you upgrade a patch version in a day, without a change advisory board meeting? If your normal deploy process for this service takes two weeks, that is your CVE response time, because there is no separate fast path unless you built one in advance.
Do you know what breaks if you get it wrong? Practising a patch upgrade in staging, including the rollback, is the difference between a Friday evening and a Sunday.
XML-based SAML processing deserves a specific mention because it has a long history of signature-wrapping and parser vulnerabilities, and it is exactly the code path that an enterprise customer forces you to turn on. If you enable SAML, you have opted into that class of bug and into patching it promptly.
Needs first-hand data: Time a full patch-version upgrade in staging, from advisory published to service healthy, including the rollback rehearsal. If that number is longer than a weekend, self-hosting the IdP is a decision you have not actually staffed. Repeat it once a quarter, because the number drifts.
Keycloak
Keycloak is the reference open source identity provider: a Java service under a permissive licence, now a CNCF project, implementing OIDC, OAuth 2.0 and SAML with realms as its multi-tenancy unit, a full admin console, user federation to LDAP and Active Directory, and an authentication flow builder that lets you compose steps without writing a service. It is the most feature-complete thing here with nothing behind a paywall, and the most operationally demanding.
Pros
- Genuinely complete protocol coverage including SAML and LDAP federation, with no enterprise edition holding anything back
- Realms give you real multi-tenancy with per-realm identity providers, clients and policies, which is the shape B2B SaaS actually needs
- The authentication flow builder and SPI extension points let you insert custom logic without forking
- The largest community and operational knowledge base of any project here, so most production problems have a public answer
Cons
- Operationally heavy: a JVM to tune, a clustering layer for cache coherence, and memory behaviour that needs attention at scale
- Major versions have historically changed significant things, including the underlying server platform and the admin API, so upgrades are projects rather than tasks
- The admin console is powerful and genuinely hard to learn, and misconfiguration is easy in ways that are quietly insecure
- Customising the login UI means theme development inside the server rather than building a page in your own frontend
Best for: Organisations that need every protocol including SAML and LDAP with nothing gated, and that have the platform engineering capacity to run a JVM service properly.
Pricing: Free open source with no paid edition and no feature gating from the project. Cost is infrastructure, the database behind it, and the engineer time to run upgrades and clustering. Commercial support is available from vendors who package it.
Ory
Ory is a set of separate services rather than one product: Kratos for identity and user management, Hydra as a certified OAuth 2.0 and OIDC provider, Keto for permissions, and Oathkeeper as an identity-aware proxy. Each is a small Go service with an API and no built-in UI, which is the defining design choice. Hydra in particular is one of the few projects here built specifically to be an OAuth server for other people, rather than a login box with OAuth bolted on.
Pros
- API-first with no opinion about your UI, so login, registration and recovery are pages you build and control completely
- Composable: run Hydra alone if you only need an OAuth server, without adopting a user database you did not want
- Go services with small footprints and straightforward container deployment, no JVM tuning
- Hydra separates the OAuth authorization server cleanly from the login and consent app, which is the correct architecture for anyone issuing tokens to third parties
Cons
- You build every screen. There is no admin console or hosted login in the open source distribution, and the flow logic on your side is real work
- Multiple services means multiple databases, upgrade cycles, config surfaces and failure modes, which is a lot of moving parts for a small team
- The conceptual model, particularly Kratos self-service flows and Hydra login and consent, takes real time to internalise and is easy to implement subtly wrong
- Documentation and examples lean toward the managed cloud offering, so purely self-hosted paths sometimes require reading source
Best for: Teams that want the identity plumbing as an API and intend to own the entire user-facing experience, especially anyone who needs a proper OAuth authorization server rather than a login form.
Pricing: Open source under a permissive licence with no feature gating in the self-hosted components, alongside a separate managed cloud from the same vendor. Self-hosted cost is several services, their databases and the engineering time to build every UI.
Authentik
Authentik is a Python-based identity provider aimed at the space between internal SSO and a developer platform: OIDC and SAML providers, a flow engine where authentication stages are composed visually, LDAP and proxy outposts that put a login in front of applications that cannot speak a modern protocol, and directory sync. It has become a common answer for homelab and internal infrastructure SSO, and it scales upward into small and mid-sized company use.
Pros
- The proxy and LDAP outposts put SSO in front of legacy applications that have no OIDC support at all, which nothing else here does as neatly
- The flow and stage model is genuinely flexible for conditional logic like step-up MFA or conditional enrolment, configured rather than coded
- Much lighter to deploy and reason about than Keycloak for the same internal SSO job
- Active development with a clear release cadence and a visible roadmap
Cons
- Open core: some capabilities aimed at larger organisations sit in a paid enterprise offering, so verify your requirements against the open build specifically
- Positioned around workforce and infrastructure SSO rather than customer-facing signup at consumer volume, and the defaults reflect that
- The flow engine’s flexibility is also its difficulty, and a misordered stage can create an authentication bypass that looks like a working config
- Smaller ecosystem than Keycloak, so unusual integration problems have fewer public answers
Best for: Teams putting SSO in front of internal tools and legacy applications, especially where proxy or LDAP outposts remove the need to modify those applications.
Pricing: Free open source core with a paid enterprise edition and support; self-hosted cost is a modest container footprint plus a database and the time to maintain flows.
SuperTokens
SuperTokens takes a middle position between a library and a full IdP: you run its core service, which owns the user and session data, and you use its SDKs in your frontend and backend so that session handling and the login UI live in your application. The session implementation is the strongest part of the product, with rotating refresh tokens and real revocation rather than the usual “JWTs cannot be revoked” shrug.
Pros
- Session management is a first-class design concern here rather than an afterthought, including refresh token rotation and server-side revocation
- Prebuilt UI components you can drop in and then progressively replace, so you are not choosing between speed and control up front
- Self-hosted core keeps user data in your own database, which resolves most data residency conversations before they start
- Meaningfully simpler to stand up than Keycloak or Ory for a standard web application
Cons
- Enterprise protocol support, particularly SAML and multi-tenant SSO, is thinner than the full IdPs and some capability sits in paid tiers
- The core service is a required dependency on the login path, so it is a component you must run well, not just a library
- Tied more closely to its SDKs than the protocol-first options, which makes a future migration to a different provider more involved
- Smaller community than Keycloak, and less public operational experience at very high volume
Best for: Product teams building a standard web or mobile application who want correct session handling and their own login UI without operating a full identity platform.
Pricing: Open source core free to self-host with paid tiers for managed hosting and some advanced features; self-hosted cost is one service, your database and the SDK integration work.
Zitadel
Zitadel is a Go identity platform built around an event-sourced data model, with organisations as the multi-tenancy primitive, OIDC and SAML support, passwordless and passkey flows as first-class rather than bolted on, and an audit trail that falls out of the architecture instead of being a separate feature. It is one of the few projects here designed from the start for both workforce and customer identity, and one of the few that self-hosts the same code the vendor runs as a cloud.
Pros
- Event sourcing means a complete, immutable audit trail of every change to identity state, which is unusually strong for compliance conversations
- Organisations and projects model B2B multi-tenancy properly, including per-organisation identity providers and policies
- Passwordless and passkey support is central to the product rather than an add-on, and the flows are coherent
- Same codebase self-hosted and in the vendor cloud, so moving between them later is a deployment decision rather than a migration
Cons
- The event-sourced store is an unfamiliar operational shape: projections, growth of the event stream and query behaviour all need understanding before you scale it
- Smaller community than Keycloak, so troubleshooting leans on the vendor and the documentation rather than a decade of forum threads
- Concept model with instances, organisations, projects and grants takes real time to map onto your own tenancy design, and getting it wrong is expensive later
- Some advanced capability and support sit behind commercial arrangements, so confirm the boundary for your requirements
Best for: B2B products that need real multi-tenancy and a defensible audit trail, from teams comfortable adopting a newer platform than Keycloak.
Pricing: Open source and free to self-host, with a managed cloud metered on usage and paid support and enterprise arrangements alongside it.
Logto
Logto is a newer open source identity service built around developer experience: an OIDC provider, a prebuilt and customisable sign-in experience, a management console, SDKs across the common frameworks, and organisation support for B2B tenancy. It aims at the gap between a library that gives you nothing and Keycloak that gives you everything including a JVM.
Pros
- Fast to a working login compared with the heavier platforms, with a sign-in experience you configure rather than build
- Clean management console and a well-shaped management API, so tenant and application provisioning automates cleanly
- Organisation model and role support cover the common B2B requirements without a separate product
- Modern SDK coverage across frontend frameworks, which removes most of the integration guesswork
Cons
- Younger project, so long-horizon questions about very large deployments and long-term support windows have fewer public answers
- Open core: enterprise protocol support and some organisation features sit in paid tiers, and that boundary is exactly where B2B requirements land
- Less extensible than Keycloak or Ory when you need custom logic inside the authentication flow itself
- Smaller operational community, so scaling and upgrade experience is thinner in public
Best for: Small product teams who want a self-hostable identity service with a good console and fast integration, and who can live inside its model rather than extending it.
Pricing: Open source core free to self-host, with a managed cloud and paid tiers gating some enterprise and organisation features; self-hosted cost is a small service plus a database.
FusionAuth
FusionAuth is a complete identity platform you can download and run for free, with a caveat worth stating plainly: it is not OSI open source. It is a commercial product with a free self-hostable community edition. What you get is unusually complete for that arrangement, including a broad set of hashing algorithms for importing users from an existing system, a flexible tenant and application model, and lambdas for customising token contents.
Pros
- Very strong user import story, with support for many legacy password hash formats, which makes migration from a home-grown system unusually tractable
- Complete platform in a single deployable with a real admin console, rather than an assembly of services
- Tenants and applications model multi-product and multi-brand setups cleanly
- Documentation is thorough and written for engineers doing the work rather than for a buying committee
Cons
- Not OSI open source, which is a hard blocker if your policy requires it or if you plan to embed and redistribute
- Advanced features including some enterprise protocol and threat detection capability are licensed, so the free edition is not the thing to compare against a commercial platform
- Single vendor with no community fork to fall back on, so the licence terms are the terms
- The breadth of configuration means the console has a learning curve comparable to Keycloak’s
Best for: Teams migrating off a home-grown auth system who need to import existing password hashes without forcing a reset, and who are comfortable with a source-available commercial licence.
Pricing: Free community edition to self-host with paid editions and hosting that unlock advanced features and support; the meter on paid plans is usage-based rather than a flat licence.
Better Auth
Better Auth is a TypeScript authentication library, not a service. It runs inside your application, writes to your database through your own adapter, and covers email and password, social providers, sessions, MFA and organisations through a plugin model. The appeal is total ownership: no separate process on the login path, no network hop, no user data anywhere but your database.
Pros
- No extra service to run, no network hop on the login path, and no separate database of record for users
- Plugin architecture covers organisations, MFA, passkeys and more without forcing a platform adoption
- Full TypeScript types across the boundary, so auth state in your application is checked rather than assumed
- Framework-agnostic within the TypeScript ecosystem, so it moves with you across meta-frameworks
Cons
- TypeScript only, so a polyglot backend either adds a service in front or reimplements verification in every other language
- You are responsible for everything an IdP would have given you: admin tooling, audit logging, rate limiting design and account recovery policy
- Enterprise protocols like SAML and SCIM are not what a library of this shape is for, and bolting them on later is a rewrite rather than a feature flag
- Younger than the alternatives, so the long tail of edge cases is still being found in public
Best for: TypeScript teams building a product where auth should be part of the application rather than a platform, and who want user data to live only in their own database.
Pricing: There is no vendor and no bill. It is an open source library you install, and the entire cost is the infrastructure it already runs on plus the maintenance and security work you take on yourself.
Auth.js
Auth.js, previously NextAuth.js, is the most widely deployed authentication library in the JavaScript ecosystem. It handles OAuth flows with a very long list of providers, session cookies, and optional database persistence through adapters. It is a library, so it gives you the protocol mechanics and leaves policy, UI and administration entirely to you.
Pros
- The broadest social and OAuth provider list of anything here, mostly as configuration rather than integration work
- Enormous install base, so nearly every integration problem has been hit and written up by somebody already
- Adapter model lets you keep users in whatever database you already run, with no separate identity store
- Works without a database at all in JWT session mode, which is the fastest possible path to a working social login
Cons
- It is deliberately not a user management system: no admin UI, no user search, no audit trail, no account lifecycle tooling
- Session revocation in the stateless mode is the usual hard problem, and solving it properly means adding the database you were avoiding
- Major version transitions in this project have historically required real migration work in application code
- Email and password is possible but distinctly not the happy path, and getting it right is on you
Best for: JavaScript and TypeScript applications whose auth requirement is social login plus a session, where the team wants no additional infrastructure at all. The Next.js-specific tradeoffs go deeper on App Router and middleware behaviour.
Pricing: There is no vendor and no bill. It is an open source library, and the cost is entirely the engineering time to configure it, extend it and keep it patched.
How to choose
Start by deciding whether you want a service or a library, because that is the only genuinely irreversible choice on this page. A library keeps auth inside your application and inside your database, and it is the right answer when you have one application, one language, and no near-term enterprise requirements. A service is the right answer the moment you have a second application, a second language, or a customer who will eventually ask for SAML.
If you want a service, filter on protocol requirements first. Needing SAML and LDAP today narrows the field sharply toward Keycloak and the commercial editions of the others. Needing only OIDC opens it right up.
Then filter on who runs it. Keycloak and Ory reward a platform team and punish a team without one. SuperTokens and Logto ask much less. Zitadel sits in between and asks you to learn an unfamiliar storage model in exchange for an audit trail you will be glad of later.
Then, before you commit, do the boundary check: find your five eighteen-month requirements in the specific edition you plan to run.
| Project | Shape | SAML in the free build | Operational weight | Picks itself when |
|---|---|---|---|---|
| Keycloak | Full IdP service | Yes | High | You need every protocol with nothing gated |
| Ory | Composable API services | Via the stack, self-built UI | High | You want an OAuth server and own the entire UI |
| Authentik | Full IdP service | Yes | Medium | Internal SSO including legacy apps behind a proxy |
| SuperTokens | Core service plus SDKs | Limited | Low | Standard web app, correct sessions, your own UI |
| Zitadel | Full IdP service | Yes | Medium | B2B multi-tenancy and an audit trail that holds up |
| Logto | Full IdP service | Check edition | Low | Small team wanting a console and fast integration |
| FusionAuth | Full platform, source available | Check edition | Medium | Migrating legacy password hashes without a reset |
| Better Auth | Library | No | None beyond your app | TypeScript app, auth belongs in the codebase |
| Auth.js | Library | No | None beyond your app | Social login and a session, zero new infrastructure |
Needs first-hand data: Run your two finalists against a realistic login load and record the p99 of a token issuance and of a token introspection or validation call, with the database sized as you would actually run it. Then kill the primary database and record how long login stays broken. Those three numbers tell you more about living with the choice than any feature matrix.
The managed alternatives to all of this, and the honest build-versus-buy arithmetic, are in best authentication providers.
Frequently asked questions
Is Keycloak still the default choice for open source auth?
For protocol completeness, yes. Nothing else here gives you OIDC, SAML and LDAP federation with zero feature gating and a decade of production knowledge behind it. The reason teams look elsewhere is not missing features, it is operational weight and upgrade friction. If you have a platform team, Keycloak is hard to argue against. If you do not, its strengths are not the ones you will feel and its costs are.
What is the difference between an open source auth library and an open source IdP?
An IdP is a separate service that owns identity for everything you run, speaks standard protocols, and has an administrative surface. A library runs inside one application, in one language, and gives you the mechanics without the platform. The moment a second application or a second language needs to authenticate against the same users, a library forces you to either build a protocol layer yourself or migrate. That transition is the main thing to predict before you choose.
Can open source auth handle enterprise SSO for B2B customers?
Keycloak, Zitadel and Authentik can, and the commercial editions of the others usually can. What none of them removes is the per-customer integration work: each enterprise customer’s IdP has its own attribute naming, its own certificate rotation practice, and its own idea of what a SAML assertion should contain. The software is the smaller half of that problem. Enterprise SSO for B2B SaaS covers what the integration actually costs per customer.
How do I avoid being locked into an open source project I later want to leave?
Keep two things portable. First, users and password hashes: know the hash algorithm and parameters in use and confirm you can export them, because a hash format you cannot export means every user resets their password on migration day. Second, token and session semantics: if your applications validate tokens using a standard OIDC discovery document and JWKS endpoint, swapping the issuer is a configuration change. If they depend on vendor-specific SDK behaviour, it is a rewrite. The mechanics are the same ones described in Auth0 alternatives.
Does self-hosting auth help with data residency and compliance?
It helps with residency directly, because the user records are in a database you chose and placed. It helps with compliance only partially. You still need audit logging that is actually retained and queryable, access controls on the admin console, evidence of patching, and a deletion process that reaches every copy of the data including backups and logs. Self-hosting hands you those obligations rather than satisfying them. Keeping the audit trail somewhere durable and searchable is the practical part, and that is a log management problem as much as an identity one.
Related reading
- Best authentication providers for developers — the full category including managed options and the build-versus-buy arithmetic.
- Best self-hosted identity providers — key rotation, session store scaling and disaster recovery for the systems above.
- Best CIAM platforms — what changes when the user population is consumers rather than employees.
- Best auth providers for B2B SaaS — multi-tenancy, per-organisation SSO and the requirements enterprise deals create.
- Best session management libraries — the revocation problem stated honestly, and refresh token rotation.
- Best SCIM provisioning tools — the provisioning requirement that arrives just after SSO does.