Get started
← All articles

Open source SSO: which solution fits your constraints

Published on · Updated on

For SAML/AD federation and broad enterprise needs, Keycloak remains the reference. For a heterogeneous estate behind a reverse proxy, Authentik or Authelia does the job with less complexity. If you are building your own interface, Ory stands out as API-first, and Zitadel dominates as soon as multi-tenancy is involved. In every case, check first which protocol your applications actually require, and turn on multi-factor authentication before you even think about migrating.

In short:

  • Most modern applications favour OIDC with the authorization code flow and PKCE, avoiding the vulnerabilities of the older implicit flows.
  • If your organisation still runs mainly on SAML, be rigorous about validating XML assertions to keep it secure.
  • Check that your chosen solution supports OIDC, SAML, SCIM, LDAP or Active Directory, along with strong authentication through WebAuthn or FIDO2.
  • Pick an open source solution under a permissive licence (Apache 2.0, MIT) to keep long-term management simple, and avoid AGPL ones if you offer your service to customers.
  • For a small business, Authentik or Authelia are simpler to install and run, while Keycloak stays relevant for federating several directories or integrating legacy software over SAML.
Cloud OS
Bring your tools together, privately
Cloud OS brings your applications together on infrastructure hosted in Quebec, with nothing to install, for Canadian small businesses and their teams.
Discover the small-business solution

Table of contents

What separates OIDC/OAuth2 from SAML 2.0?

OIDC (OpenID Connect) and OAuth2 dominate modern web applications and APIs. The preferred flow is the authorization code combined with PKCE, an extension that protects the token exchange even on public clients such as mobile apps or single-page apps. The Canadian Centre for Cyber Security explicitly recommends this flow over the older implicit flows, judged more vulnerable to token interception.

SAML 2.0, for its part, remains entirely relevant for large organisations and existing federations. A lot of enterprise software — HR suites and government portals in particular — speaks only this XML-based protocol. If your business integrates with a partner or a client that mandates SAML, you do not really have a choice.

The practical consequence plays out in attribute mapping. With OIDC, user information travels in a JWT structured as JSON, which simplifies debugging and integration on the developer side. With SAML, XML assertions demand stricter validation of fields such as issuer, recipient and validity window, on pain of opening a breach. OWASP details those checks precisely in its SAML hardening guide.

Session handling and sign-out also differ markedly. OIDC handles logout relatively simply through a dedicated endpoint, whereas SAML single logout involves synchronising across several service providers — often a source of bugs in production. If your organisation mixes legacy SAML applications with recent OIDC cloud services, plan for an identity provider that speaks both without compromise, which immediately shortens the list of serious candidates.

What separates OIDC/OAuth2 from SAML 2.0 — overview diagram

Which criteria should you validate before choosing?

Before committing to a project, work through this checklist. It avoids the nasty surprises that show up six months after deployment, when changing course is no longer painless.

  • Protocol compatibility: confirm the solution speaks OIDC, SAML 2.0, and ideally SCIM for automated account provisioning, plus LDAP or Active Directory if you already have a directory.
  • Strong authentication: check for WebAuthn and FIDO2 support, the methods the Canadian Centre for Cyber Security calls phishing-resistant, to be preferred for administrator accounts.
  • Account lifecycle: SCIM provisioning must cover creation, but also immediate revocation when an employee leaves — a point often overlooked.
  • Operational requirements: anticipate high availability, a robust external database such as PostgreSQL, a backup strategy and a minimum of observability (logs, metrics, alerts).
  • Licence and governance: distinguish projects under Apache 2.0 or MIT, generally more permissive for commercial use, from AGPL projects, which impose code-sharing obligations if you modify the service and expose it publicly.

That last point deserves digging into, because it governs your long-term freedom. An AGPL licence does not prevent internal use, but it changes things if you plan to offer your own platform built on that identity engine to outside customers. Always check the exact terms before building a strategic dependency.

Pro tip: Never choose an SSO solution on the richness of its feature list alone. List your three most critical applications first and check their exact protocol before comparing anything.

What do the most-used open source SSO projects actually offer?

Each project has a distinct operational personality. Here is what really separates them, beyond the feature table.

Keycloak covers the widest protocol surface: OIDC, OAuth2, SAML 2.0, LDAP/Active Directory federation, and a system of "realms" to isolate distinct organisations. Keycloak remains the default choice when your business has to federate several corporate directories or integrate legacy software over SAML. The downside: its memory footprint is markedly heavier than its competitors, and the administrative learning curve demands a real investment of time.

Authentik bets on an architecture of "outposts", small agents deployed at the edge that handle authentication in reverse-proxy mode for applications that natively support no SSO protocol at all. Its visual administration interface, with drag-and-drop configurable flows, makes it a good compromise for a small business without a dedicated security team. It handles OIDC and SAML, but with less depth than Keycloak on complex federation scenarios.

Authelia aims at a more modest goal and hits it well: quickly protecting a set of services behind a reverse proxy such as Traefik or nginx, with a minimal memory footprint. It is not a full identity provider in the SAML sense, and it does not replace Keycloak for enterprise federation. Authelia's positioning centres on lightweight forward-auth, perfect for securing a homelab or a small infrastructure without demanding a server dedicated to identity.

Ory, with its pairing of Hydra for OAuth2/OIDC and Kratos for identity management, takes a fully API-first approach. There is no ready-made user interface: you code your own sign-in experience against the APIs. That is demanding in development, but it offers total control over the final experience — a logical choice if you are building a SaaS product where identity has to sit natively inside your brand.

Zitadel stands out with an event-sourced architecture and native multi-tenancy, designed for B2B platforms that must isolate hundreds of customer organisations on a single instance. The comparison between Keycloak, Authentik and Zitadel notes that Zitadel suits teams leaving a proprietary SaaS provider and wanting control back. One point to check carefully: some advanced Zitadel features are under AGPL, which has implications if you redistribute the service.

Three projects round out the landscape for more targeted needs:

  • Dex acts as a simple OIDC connector federating existing identity sources (LDAP, social networks, SAML) without managing passwords itself — ideal alongside a Kubernetes cluster.
  • FreeIPA targets centralised identity management the old way, combining LDAP, Kerberos and a certificate authority — a relevant choice if your organisation still runs largely on Linux and demands deep system integration.
  • Casdoor offers modern administration with social sign-in built in, an interesting option for a consumer-facing product rather than for pure internal access management.

How do you deploy and run an open source identity provider?

An identity provider in production is never a container you launch and forget. Nearly all the projects mentioned (Keycloak, Authentik, Zitadel) recommend an external database such as PostgreSQL rather than the default embedded one, as soon as you move past testing. That database becomes your single point of failure: schedule automated backups and regularly test restoring them, not merely running them.

SSO architecture with an external database and backups

On resources, Keycloak generally demands more memory than Authentik or Authelia for an equivalent number of active users — a factor to weigh if you deploy on limited infrastructure outside a major centre, for instance a business in Abitibi-Témiscamingue where bandwidth and local server resources are more constrained than in an urban area. A high-availability architecture requires at minimum two instances behind a load balancer, with the database as the shared component.

Updates deserve particular attention with open source projects. Unlike a managed service, nobody pushes a fix on your behalf: you have to actively watch each project's security bulletins and plan maintenance windows. Periodically rotating JWT and SAML signing keys, and keeping searchable audit logs, complete a serious operational baseline. Without minimal observability (metrics, alerts on repeated authentication failures), you will discover a security problem long after it has done damage.

Which security practices apply to your SSO deployment?

A badly configured identity provider becomes the number one way into all of your applications. The following recommendations are not optional.

  • Turn on multi-factor authentication by default, and prefer FIDO2/WebAuthn methods for high-privilege accounts, as the Canadian Centre for Cyber Security advises.
  • Never store access tokens in browser localStorage, which is vulnerable to script attacks; prefer HttpOnly, secure cookies, or a backend-for-frontend architecture that keeps tokens on the server.
  • On SAML integrations, systematically validate the signature, the issuer, the recipient and the InResponseTo field to block unsolicited responses — a requirement detailed in OWASP's SAML guide.
  • For OAuth2/OIDC flows, apply PKCE systematically, even for confidential clients, and consider binding tokens to the client through DPoP or mTLS where possible, as OWASP recommends in its OAuth2 guide.
  • Log every failed authentication attempt and every role change, and keep those logs long enough to support an investigation if there is an incident.

Worth remembering: the Canadian Centre for Cyber Security identifies the authorization code flow with PKCE as the reference configuration for OAuth2 and OIDC, as against implicit flows now judged obsolete for any new integration.

How do you migrate your applications to open source SSO?

A successful migration follows a precise order, with no shortcuts.

  1. Inventory each application and its actual protocol (OIDC, SAML, or none), along with the attributes it expects back.
  2. Choose a stable identifier for each user rather than the email address alone, which can change over time.
  3. Test in a sandbox environment, then run a restricted pilot before deploying in batches.
  4. Plan a break-glass access path outside SSO for sites with intermittent connectivity — a frequent reality in mineral exploration in Quebec.

Pro tip: Document each application's attribute mapping before the switch. It is usually the first thing forgotten, and the first cause of support tickets on launch day.

What should actually decide it

The question is never "which open source SSO is best", but "which constraint dominates here: federation, heterogeneity, multi-tenancy or API-first". Check the licence before getting attached to a project, and prototype with a real use case before generalising.

— Maxime

An alternative that shrinks the integration surface

For a small business, running an open source identity provider in house is a project in its own right: database, backups, security updates, continuous monitoring. Cloud OS takes another direction, bringing your working tools together (office documents, image processing, video editing, geomatics with QGIS) directly inside a cloud environment hosted on servers owned in Quebec, with nothing installed locally and without you having to run a separate identity server for each application.

Cloud OS

Your data and your processing stay on that local infrastructure, which answers directly the digital sovereignty concern any federated identity project raises. Pricing is a subscription, and everything is in it: two plans, a monthly usage gauge rather than a per-task invoice, and a 14-day trial with no card. See the full plans and pricing, or explore the features available — the Sandbox, a persistent Linux desktop, comes with the Business plan.

Sources

Frequently asked questions

What is an open source SSO solution?

An open source SSO solution is an identity provider whose source code is public, letting you centralise authentication across several applications with a single set of credentials. Keycloak, Authentik, Authelia, Ory, Zitadel, Dex, FreeIPA and Casdoor are among the most widespread projects.

SSO vs MFA: are the two technologies opposed?

No, they are complementary: SSO centralises access to several applications with a single sign-in, while multi-factor authentication adds a further verification layer during that sign-in. The Canadian Centre for Cyber Security recommends combining both, with FIDO methods for sensitive accounts.

Which open source SSO suits a small business best?

For a small business with a heterogeneous application estate and little dedicated technical staff, Authentik or Authelia take less running than Keycloak. If your business has to federate several directories or integrate enterprise software over SAML, Keycloak remains the most complete option despite its complexity.

Is there a free SSO system with no licence fees?

Yes. Keycloak, Authentik, Authelia, Ory, Dex, FreeIPA and Casdoor are distributed under free licences such as Apache 2.0 or MIT, with no licence cost. Zitadel offers some features under AGPL, which imposes code-sharing obligations if you redistribute the modified service.

Should you choose OIDC or SAML for a new integration?

OIDC suits the great majority of modern web applications and APIs, since it rests on JSON tokens that are simpler to process. SAML remains necessary for legacy enterprise software and existing federations that offer no alternative.

Can a small business avoid running its own SSO server?

Yes, by bringing the working tools together inside one cloud environment rather than multiplying the applications to federate. Cloud OS takes that approach with local hosting and an all-inclusive subscription, with nothing to install and no identity server to maintain in house.

Cloud OS
Tell us about your digital environment
Talk to Cloud OS about bringing your applications together, keeping your data private and what your infrastructure actually needs.