Open Source SSO
Single sign-on quietly becomes the most load-bearing service you run: once every app has learned to trust it for login, it sits in the critical path for all of them, and that is exactly what makes it the hardest thing to ever replace. The protocols it speaks matter more than its feature list, because open standards like OIDC and SAML are your only clean exit path when an app has to be pointed somewhere new. The open source identity providers here implement those standards in the open and run on infrastructure you control, so your user directory and the trust every application places in it stay portable rather than welded to one vendor's login.
Keycloak
Open source identity and access management for adding authentication, user federation, and authorization
Authelia
Open-source SSO and multi-factor authentication portal for applications behind reverse proxies
authentik
Open-source identity provider for SSO with SAML, OAuth2/OIDC, LDAP, and RADIUS
Teleport
Identity-aware infrastructure access with short-lived certificates and audit across SSH, Kubernetes, databases, and RDP
Ory Hydra
OpenID Certified OAuth 2.0 and OpenID Connect server for SSO, API access, and machine-to-machine authorization
SuperTokens
Open-core user authentication with login, session management, and on-premises control of user data
ZITADEL
Open-source identity infrastructure for SSO, MFA, passkeys, OIDC, SAML, and SCIM
Casdoor
AI-first identity and access management platform with MCP gateway and web UI
Ory Kratos
API-first identity and user management for login, registration, recovery, verification, and profile flows
Our picks
Pick by the job: workforce login, a product's identity layer, legacy apps, or infrastructure access.
Mature general-purpose identity provider: Keycloak Keycloak centralizes authentication so applications stop storing and checking their own passwords, with user federation, fine-grained authorization, and both OIDC and SAML. A CNCF project that runs as a standalone distribution or a container, it is the default starting point for one self-hosted identity provider across a mix of apps.
Broad protocols and a proxy for legacy apps: authentik authentik speaks SAML, OAuth2/OIDC, LDAP, and RADIUS from one self-hosted server, and its Application Proxy adds forward-auth SSO to apps that have no authentication of their own. It adds customizable login flows plus WebAuthn and TOTP for MFA. A good fit when your estate mixes modern apps, old internal tools, and network gear.
Multi-tenant identity with an audit trail: ZITADEL ZITADEL is built API-first around strict multi-tenancy and writes every change as an immutable event for an API-accessible audit trail. It covers SSO, MFA, passkeys, OIDC, SAML, and SCIM, and the cloud and self-hosted builds share one codebase. Strong for B2B SaaS products that need tenant isolation and provable history.
SSO for servers and infrastructure: Teleport Teleport applies identity to infrastructure rather than web apps, protecting SSH, Kubernetes, databases, and Windows desktops with short-lived certificates instead of long-lived keys. It adds unified RBAC, session recording, and audit, and consumes SSO from GitHub, OIDC, or SAML. Use it alongside a general identity provider to govern engineer access to production.
Choosing an identity provider you can afford to live behind
This category hides several different jobs under one label, so name yours first. Full identity providers like Keycloak, authentik, and ZITADEL own your users, groups, and login screens and speak OIDC and SAML to every app. Developer-facing auth infrastructure such as SuperTokens, Logto, Ory Kratos, and Hanko is meant to be embedded in a product you are building, handling sign-up and sessions behind your own UI. Authelia is a reverse-proxy portal that adds SSO and MFA in front of apps that have no auth of their own, and Teleport secures access to servers, Kubernetes, and databases rather than web apps. Evaluating across the wrong group is the usual reason a comparison stalls.
Within the right group, test protocol fit against your real apps, not a demo. Modern web and mobile apps want first-class OIDC; enterprise SaaS often requires SAML; older internal software may need LDAP or header-based auth; and provisioning wants SCIM. Casdoor and ZITADEL cover the widest protocol spread including SCIM, while Dex is deliberately narrow, acting as an OIDC front end over upstream directories like LDAP and Active Directory. Treat deployment as a security decision too: the server joins the login path for nearly every app, so you need a clear story for clustering, database dependencies, key storage, and recovery after a node fails.
Finally, look past the login box to the identity lifecycle. SSO is only useful if users, groups, and app assignments stay accurate through onboarding, role changes, and departures, so check SCIM provisioning, directory sync, delegated administration, and audit logs that explain who changed access. The exit path is the protocols themselves: if your apps use standard OIDC, SAML, LDAP, and SCIM, moving to another provider is planning rather than rescue, and the real risk lives in custom themes, plugins, and undocumented client settings.
Related categories
Frequently asked questions
What is the difference between an identity provider and embeddable auth infrastructure?+
An identity provider like Keycloak, authentik, or ZITADEL is a standalone system that owns your users and login screens, and every app federates to it. Embeddable infrastructure such as SuperTokens, Logto, or Ory is built into a product you ship, handling authentication behind your own UI and data model. Choose an identity provider to centralize workforce login; choose embeddable auth when you are adding sign-in to an application you build.
Which protocols does my SSO actually need to speak?+
Match protocols to your real apps. Most teams need OIDC for modern web and mobile, SAML for enterprise SaaS, LDAP for older internal systems, and SCIM for provisioning; VPNs and network gear may add RADIUS. authentik and Casdoor cover the broadest spread including LDAP and RADIUS, while Dex focuses on OIDC over upstream directories. Test the exact claims, group mappings, and logout behavior your applications expect, not a single protocol demo.
Do these handle passkeys and MFA, or do I add those separately?+
Most include strong authentication rather than leaving it to bolt-ons. Authelia and ZITADEL support WebAuthn and FIDO2 passkeys plus TOTP, Hanko is built around passkeys, and Casdoor adds TOTP and Face ID. Look beyond whether MFA exists to policies that vary by group, network, or app, and to the recovery flow, since a weak help-desk reset can quietly undo even strong second factors.
What happens to the rest of my stack if the SSO server goes down?+
Existing sessions often keep working, but new logins, token refreshes, and provisioning fail while the server is down, so the blast radius depends on token lifetimes and how apps validate sessions. Treat SSO like DNS or the primary database: plan redundant nodes, database failover, health checks that exercise a real login path, and break-glass admin access for when your directory or network is unavailable.
Can SSO cover infrastructure like SSH and databases, not just web apps?+
Yes, but that is a distinct tool. Teleport is built for infrastructure rather than web apps, giving identity-aware access to SSH servers, Kubernetes clusters, databases, and Windows desktops with short-lived certificates instead of shared keys, plus session recording and audit. It can consume SSO from GitHub, OIDC, or SAML, so it usually sits alongside a general identity provider rather than replacing it.
How do I add SSO to an app that has no login of its own?+
Two patterns work. A reverse-proxy portal like Authelia sits in front of the app and allows, denies, or redirects requests before they reach it, and authentik's Application Proxy adds forward-auth SSO the same way. Both target software with no native authentication. Test deep links, logout, and session timeout, since apps that were never designed for external auth can behave oddly at the edges.
Does SSO replace the permissions inside each application?+
No. SSO proves who the user is and can pass attributes like groups, roles, or department, but each application still decides what that user can do unless it delegates authorization explicitly. Keep group names stable, map claims predictably, and use SCIM where possible so app accounts are provisioned automatically. Expect to clean up permissions inside each app during migration rather than assuming SSO handles them.