At Cerbos, we’ve chosen to build an open source product first. That was a deliberate decision to make a scalable authorization engine available to the community. And we love seeing that many powerful authentication and authorization tools are following the open source path as well.
My guide will walk you through open-source authentication and authorization tools that our community has recommended. Also, in my follow-up article, I’ll highlight best practices for implementing secure authentication and authorization at scale (we actually have the whole ebook on building scalable authorization).
You’ve probably heard people use authentication and authorization interchangeably, but in practice, they solve very different problems. Authentication answers the question of who is making a request. Authorization decides what that identity can actually do once inside a system. Both are required if you want secure identity and access management that scales. Get authentication wrong and unverified users (or AI agents) slip in. Get authorization wrong and even trusted users can reach data or actions they should never touch or see. If you want to map this to familiar terms: AuthN is what powers things like SSO, MFA, and identity federation. AuthZ is where concepts like RBAC, ABAC, fine grained permissions, and least privilege enforcement come into play.
In my guide, I use “auth” as shorthand for both authentication and authorization. When we talk with our customers, we typically use AuthZ for authorization and AuthN for authentication.
NOTE
The tools listed cover different parts of the identity and access stack. Some are full identity providers, others are lightweight authentication services, authorization engines, token services, or even network-layer identity overlays. I grouped them under one umbrella because teams often evaluate these side by side when choosing the IAM stack.
I’ve analyzed 13 open source auth tools, most of which are self hosted. The tools are listed in alphabetical order and at the end I’ll share a practical framework for evaluating them.
If you know of a tool I’ve missed, feel free to drop me an email at lisa at cerbos.dev.
Authelia is a self-hosted authentication server that sits behind reverse proxies. It provides centralized login, MFA, and single sign-on. It supports passwordless login via WebAuthn, OTP-based MFA, hardware keys, and push notifications (via external providers such as Duo).
Authelia also supports access rules, such as restricting specific services to certain user groups, but it does not offer fine grained authorization. If you need resource-level or contextual permission checks, you would integrate Authelia with another system that handles authorization.
It relies on PostgreSQL and Redis for scalability, and its build pipeline is hardened with signed releases to improve security and supply chain trust. So, what can you use Authelia actually for? In practice, it works best as an authentication gateway for apps running behind reverse proxies like Traefik or NGINX, where you need MFA and SSO without deploying a full identity provider.
Key features:
Pros | Cons |
---|---|
- Lightweight tool - Hardened build pipeline and minimal runtime image - Rate limiting and account lockouts against brute force - Straightforward deployment with Docker or Kubernetes - Fewer disclosed vulnerabilities so far (compared to Authentik)* |
- Missing advanced features (federation, SCIM, compliance dashboards) - Authorization is limited to simple access rules - Push notifications rely on external providers - No managed option |
The last point in the Pros section talks about the recent comparisons of disclosed vulnerabilities between Authelia and Authentik. Authentik has had 22 CVEs reported, including 11 rated high or critical. Authelia has had only 3, with one critical (CVE-2021-32637 affecting NGINX with a specific module). The lower count is partly due to Authelia’s narrower scope and smaller attack surface, since it does not ship a large admin UI. Anyway, this was just an interesting detail to add to this section.
Authentik is a self-hosted identity provider that handles authentication with MFA, SSO, and protocols (OIDC, OAuth2, SAML, LDAP). It can also act as a reverse proxy, enforcing authentication and MFA in front of apps that lack native support. Compared to lighter tools, Authentik has a broader feature set, including group- and role-based access rules, customizable flows, and a Remote Access Component for RDP, SSH, and VNC. The key features section perfectly shows how powerful this AuthN tool is.
The trade-off is complexity and overhead:
Even simple setups often require multiple stages, and advanced scenarios may need custom Python code. Community feedback is consistent: as you saw in the image above, Authentik is harder to learn than other authentication tools, and not easy to replace once it sits deep in your stack.
Key features:
Pros | Cons |
---|---|
- Proxy mode wraps legacy systems with modern login - Built-in RAC reduces the need for separate Guacamole setups - The impersonation feature is practical for troubleshooting - Custom flows and policies make it highly adaptable |
- Setup and configuration are complex - Advanced scenarios often require Python scripting - Heavier resource use compared to alternatives - Double login issues if apps do not support SSO natively - No managed or enterprise option |
Cerbos PDP is a self hosted, open source authorization engine built for enterprise application stack that requires fine grained and contextual access control. Cerbos enforces fine grained authorization policies across apps, APIs, workloads, service accounts, MCP servers, and agentic AI systems. It is built to handle authorization for both existing software and new AI-powered systems (if you want to learn more about service-to-service authorization, we have a good guide here).
Cerbos is optimized for sub-millisecond policy evaluation without requiring synchronization of external state, making it well suited for high throughput and latency sensitive systems. The stateless design allows Cerbos PDP to run anywhere in your infrastructure (in the cloud, on premises, at the edge, or directly on end-user devices).
Cerbos supports the principle of least privilege and aligns with the Zero Trust security model. Policies are externalized from application code, which makes them easier to version, test, and audit. It is a recommended solution for fine grained authorization management when security, reliability, speed, and scalability are critical requirements.
Key features of Cerbos PDP:
Pros | Cons |
---|---|
- Consistent authorization for every user, service, and workload in your stack - Policy updates do not require code changes or redeployments - Easy to start with, no steep learning curve - Once deployed, runs reliably with little operational overhead - Self-hosting and managed SaaS version available |
- Advanced enterprise features such as policy authoring UI, programmatic policy management, and interactive playgrounds are available only in the commercial Cerbos Hub - Cerbos PDP only handles authorization and must be paired with an authentication system |
Shameless plug: Thanks for reading this far. If you find my guide useful, consider giving Cerbos a ⭐ on GitHub: https://github.com/cerbos/cerbos. Every star helps, and if you’re evaluating permission management solutions, we’d love for you to give Cerbos a try.
Just like Ory Hydra (down the list), Dex is an OpenID Connect (OIDC) and OAuth 2.0 provider that functions as an identity broker rather than a full identity management system. It acts as a central proxy to your existing identity providers, such as LDAP, GitHub, or Active Directory. This allows your applications to integrate with a single OIDC flow, while Dex handles the complexity of federating with various backend systems. This makes it a popular choice for securing cloud-native infrastructure, like Kubernetes clusters, with a consistent authentication layer.
Dex is built to be lightweight and stateless. It requires a persistent database (PostgreSQL, MySQL, or etcd) for storing client registrations and sessions. As it lacks an admin UI, all configuration must be handled programmatically via static files or its gRPC API.
Key features:
Pros | Cons |
---|---|
- Lightweight and modular - Acts as an identity hub for simplified federation - gRPC APIs are ideal for microservices and automation - Kubernetes-native deployment - Simple and predictable in its core function |
- Few supported storage options - Lacks a built-in admin UI - Token refresh and group claims support depend on the specific connector - Not a user management system; requires a separate IdP* |
NOTE
An Identity Provider (IdP) is a system that creates, manages, and verifies digital identities to enable secure access across applications, APIs, and infrastructure.
IdPs authenticate users by checking credentials or other factors, then issue tokens (via SAML, OAuth2, or OpenID Connect) that downstream services trust for access. Core functions include authentication, single sign-on, federation with external directories, and user provisioning and deprovisioning. Examples of open source IdPs are Keycloak, Zitadel, and Authentik, while commercial options include Okta, Ping Identity, and Microsoft Entra ID.
Gluu is a long-standing open source IAM platform that bundles multiple components to provide a centralized IAM system. It supports major identity standards (OAuth2, OIDC, SAML, SCIM, UMA, RADIUS), making it closer to enterprise products like Ping or ForgeRock than lighter IdPs such as Authelia or Dex.
Gluu can act as the primary identity provider for SSO, issue and validate tokens, enforce MFA, and integrate with external IdPs. It includes admin UIs, APIs, and scripting hooks for custom business logic. With features like token-based access control, passwordless login, and support for both customer and workforce IAM, Gluu is a comprehensive open-source IAM option (here you can see other non-OSS IAM tools).
The product has been around for over a decade and is available as both a community edition and a commercial Flex product.
Key features:
Pros | Cons |
---|---|
- Broad standards support and protocol coverage - Passwordless authentication and adaptive MFA - Rich API catalog for integrations - Flexible scripting to extend authentication flows |
- Complex setup and heavy resource requirements - Some enterprise features are only available in the Flex edition - No native Windows support - Scaling requires tuning and maintenance |
Hanko is an open source authentication service that makes it easy to adopt passwordless login. This is one more self hosted authentication tool in my list, though it is also available as a managed service through Hanko Cloud.
Unlike broader identity providers, Hanko focuses on authentication and user onboarding rather than full identity lifecycle management.
Hanko supports multiple authentication methods, including passwords, passkeys, multi-factor authentication, social logins, and SAML-based SSO. You can integrate it quickly through Hanko Elements web components or SDKs for JavaScript, iOS, Android, React Native, and Flutter (I saw a lot of positive feedback around Hanko Elements on Reddit threads).
Its API first design allows flexible configuration modes, such as passkey only or OAuth only, and supports server-side sessions, remote revocation, and webhooks.
Key features:
Pros | Cons |
---|---|
- Privacy-first approach with data minimalism and phishing resistance - Quick to integrate using APIs, SDKs, and drop-in web components - Lightweight |
- Does not provide the full identity provider feature set - Limited ecosystem and enterprise adoption compared to larger IdPs |
Probably, you have heard of Keycloak, as it’s pretty often recommended in other guides and on Reddit. Keycloak is a self-hosted Java-based identity and access management system. It’s primarily focused on authentication and supports Single Sign-On, MFA, social logins, and federation with external identity providers. Authorization is limited to RBAC and resource-based rules with UMA 2.0, so most teams use Keycloak mainly as the identity provider and token issuer.
For fine grained authorization, most teams integrate Keycloak with a dedicated policy engine (here is our guide on using Cerbos with Keycloak for AuthN).
I also reviewed a few active Reddit discussions, and there was a consistent pattern: Keycloak is stable and widely supported in enterprise and legacy environments, but heavy to run, complex to configure, and resource-intensive compared to lighter tools (Authentik or Authelia).
Key features:
Pros | Cons |
---|---|
- Very stable once configured - Supports all major auth protocols (OIDC, OAuth2.0, SAML 2.0) - Container-friendly deployment (Docker, Kubernetes) - Flexible integration with legacy systems - Managed enterprise option available via Red Hat |
- Setup can be complex - Authorization features are limited (coarse-grained only) - Performance tuning requires manual configuration - Upgrades and custom extensions often need significant effort - Documentation gaps - Heavy resource usage compared to lighter alternatives |
A lot of these points are echoed in community feedback. One Reddit comment sums it up well:
Ory Hydra is an OAuth2 and OpenID Connect server that issues standards-compliant tokens at scale. It is part of the Ory ecosystem, which provides modular components for building a full identity and access stack.
Hydra is not a full identity provider: it does not manage users or groups. Instead, it focuses purely on OAuth2 and OIDC flows, leaving user management and authentication to other tools. This makes it popular in architectures where you want to keep the token service separate and integrate it with your own IdP or custom logic.
I decided to add it because it can be an important building block for authentication in enterprise systems.
Hydra is OpenID Certified and designed for cloud-native environments. It scales horizontally, is stateless for token handling, and integrates well with Kubernetes. A persistent database such as PostgreSQL or CockroachDB is required to store client registrations, consent sessions, and grants.
Key features:
Pros | Cons |
---|---|
- Standards-compliant OAuth2 and OIDC implementation - Modular by design; integrates cleanly into custom stacks - Native support for Prometheus - Cloud-native scaling with containers and Kubernetes |
- Not a full IAM solution; needs Ory Kratos or another IdP for user management - Requires a login and consent app to function, adding deployment complexity - Relies on PostgreSQL or CockroachDB |
Supabase Auth is the authentication and identity service inside the Supabase platform. It is built on GoTrue (originally from Netlify) and issues JWTs that integrate directly with PostgreSQL Row-Level Security (RLS). This design makes it appealing if you want authentication tightly coupled to the database without introducing a separate IdP.
It handles the basics well, covering social logins, email magic links, and phone-based OTP. Those identities are passed into JWTs, which Postgres can then use to enforce access rules through policies.
Authorization logic lives in database policies, and features like multi-tenancy or enterprise federation are missing. As one community member put it, Supabase “does authentication, but authorization is something you build yourself.” There is no built-in role-based permission system today, so you must model it manually with tables, relationships, and Postgres RLS:
Key features:
Pros | Cons |
---|---|
- Tight integration with Supabase’s broader ecosystem (storage, functions, real-time APIs) - Supports passwordless, OTP, and social logins out of the box - CAPTCHA protection reduces automated abuse |
- Limited to Postgres; cannot be used with other databases - Authorization is manual and must be built on top of RLS - Multi-tenancy may not be supported long-term - Backward compatibility across releases is not always guaranteed |
If you want to see how to extend Supabase with fine grained authorization, check out our guide on using Supabase with Cerbos.
SuperTokens is an open source authentication solution focused on delivering simple login flows. It provides prebuilt UI components, APIs, and backend SDKs that make it easy to implement common authentication patterns such as email and password, passwordless login, social logins, and multi factor authentication. Unlike full identity providers, SuperTokens positions itself as a lightweight alternative that you can self host or use as a managed service.
The product is designed to be framework-friendly. It integrates with frontend frameworks like React, Next.js, and Vue, and offers backend SDKs for Node.js, Go, and Python. This makes it attractive for teams that want to add authentication quickly without pulling in a large IAM platform.
SuperTokens also supports session management out of the box, which reduces the need for you to build your own secure session handling logic.
Key features:
Pros | Cons |
---|---|
- Quick to integrate with minimal setup - Prebuilt UI reduces frontend development effort - Secure session management is included by default - Self-hosting available alongside managed SaaS |
- Does not handle broader identity management or advanced authorization - Smaller ecosystem and enterprise adoption compared to larger IdPs - Complex requirements like federation or SCIM provisioning are not supported |
ZITADEL is a cloud-native identity provider written in Go. It supports authentication features such as SSO, MFA, and passwordless login via WebAuthn, and is available both self-hosted and as a managed SaaS. Its architecture is event-sourced, which means every identity operation is stored as an immutable event. This provides strong auditability and replay capabilities, but also requires planning for storage growth.
Like Cerbos, ZITADEL supports multi-tenancy: organizations, projects, and policies can be scoped and branded independently. You also get options like brute force protection and checks for breached passwords out of the box. You can use ZITADEL’s APIs, SDKs, and Terraform provider to automate configuration and fit it into cloud native workflows.
Compared to Authentik, ZITADEL upgrades are more predictable and do not spawn extra workers at runtime, which reduces maintenance complexity.
Key features:
Pros | Cons |
---|---|
- Predictable upgrades - API-first design with Terraform makes automation straightforward - Event-sourced audit log - gRPC support aligns well with microservice architectures |
- No LDAP interface; only external LDAP login without sync - Requires oauth2-proxy or similar for apps lacking OIDC/SAML support - gRPC APIs depend on HTTP/2 - Storage is limited to PostgreSQL and CockroachDB |
Community feedback echoes many benefits mentioned in my table:
Auth.js is an open source authentication library designed for JavaScript and TypeScript apps. It is especially popular in the Next.js ecosystem, where it provides built-in support for OAuth, OpenID Connect, and session management. Auth.js handles secure cookies, CSRF protection, and token refresh logic, which reduces the need for custom session code.
Auth.js does not manage user directories or provisioning. Instead, it acts as a lightweight middleware layer that connects apps to external identity sources and keeps track of authentication state. This makes it a strong choice for teams who want to build authentication directly into their web applications without adding a separate server or service.
Better Auth is a lightweight, open source authentication library that focuses on simplicity and framework-agnostic design. It provides a clean API for implementing login flows, issuing tokens, and managing user sessions without requiring developers to operate a full identity provider. Unlike heavier solutions, Better Auth is designed to run directly inside apps.
The library supports common authentication flows, while leaving advanced identity management to other tools. Its minimal configuration approach makes it appealing when you need to add secure authentication quickly across different frameworks or environments. While it does not provide features like federation, provisioning, or advanced authorization, it excels at embedding basic authentication logic directly in code.
In enterprise settings, it is often paired with external authorization systems or larger identity providers to fill gaps in compliance and lifecycle management.
With so many options, it’s easy to fall into analysis paralysis. So what are the frameworks to evaluate auth providers and solutions? You should consider five key pillars: security, reliability, performance, scalability, and ease of use.
Security means strong protection of identities, credentials, and tokens. Reliability is about whether the system can stay up and consistent under real-world load. Performance covers how much latency the tool adds and how it affects user experience. Scalability looks at whether it can grow with your users, applications, and workloads. And ease of use comes down to developer experience, integration effort, and how simple it is to maintain over time.
The result is that you need to think not only about what the tool does, but also how it behaves in production, how much effort it will take to operate, and whether it will still be the right choice as your needs evolve. Let’s briefly talk about each of these factors.
Security
Security is the first thing you should evaluate when looking at any auth tool, whether it handles authentication or authorization. On the authentication side, this means how the system protects credentials, secrets, and tokens, and whether it supports methods like MFA and SSO. On the authorization side, it means making sure access decisions are enforced consistently, auditable, and resilient to vulnerabilities that could expose sensitive data or actions.
Compliance teams will ask these questions anyway, so it is better to know where your tool stands before they do.
Keycloak and Zitadel have long histories of patching CVEs but need careful ops to stay current. Supabase ties authorization directly to Postgres RLS, which is powerful but couples your access rules to one database backend.
Cerbos PDP improves security on the authorization side by externalizing checks into policies that can be versioned, tested, and reviewed. Every decision is logged for auditability, and all requests are verified in real time to align with Zero Trust principles.
Reliability
Reliability is another critical factor when evaluating auth tools. If your authentication or authorization system goes down, your entire platform may go with it😀. You should look at whether the tool supports clustering, replication, and multi-region deployments to avoid single points of failure.
Keycloak is proven in large enterprise setups, but it is often described as heavy and complex to tune for high availability. Authelia is simpler but leaves more of the scaling and reliability work to you.
Cerbos takes a lightweight, stateless approach. You can run multiple policy decision points close to your services, which removes single points of failure and makes it easy to add redundancy as you scale.
Performance
Performance matters because authentication usually runs once per session, but authorization checks happen constantly. If the system adds noticeable latency, your users will feel it. You should evaluate how quickly the tool issues tokens, enforces policies, and handles load under real traffic.
Keycloak and Dex are reliable for token issuance, but their built-in authorization is not designed for low-latency, fine grained checks.
Cerbos is optimized for high-frequency authorization paths. Policies are evaluated in microseconds, and built-in caching reduces latency even further in production workloads.
Scalability
Scalability is another key pillar, since identity needs often grow faster than expected. You may start with basic workforce SSO, but before long, you also need multi-tenancy, API keys, and workload identities. The right tool should handle that growth without forcing a major re-architecture.
Zitadel builds multi-org support directly into its core, while scaling Keycloak clusters or adding new federation rules can become complex. Supabase ties authorization tightly to Postgres, which limits flexibility if your stack changes.
Cerbos scales horizontally with your services and policies, so you can manage thousands of identities and permissions without rewriting your app. As non-human identities (workloads, agents, APIs) multiply in your stack, Cerbos provides a consistent authorization layer that scales the same way for both humans and machines.
Extensibility
Extensibility matters when your requirements change: a new product, a new customer type, or a new compliance rule. Authentik gives you customizable flows but often requires Python scripting. Supabase pushes everything into database policies, which can be hard to scale.
Cerbos was built to adapt. You can go beyond static RBAC with contextual roles, use CEL for complex conditions, apply hierarchical policies across orgs or regions, and even push authorization down into data queries with its Query Planner. That flexibility means you can evolve policies as your application and user base grow, without ripping apart your access model.
Operational burden
Open source tools in my article are self-hosted. As you know, self-hosted authentication and authorization solutions are systems you deploy and manage yourself, typically on your own infrastructure or cloud.
They give you full control over data and configuration, but also shift responsibility for updates, monitoring, and reliability onto your team. Keycloak is known to be heavy to configure and tune. Authelia is easier to run but limited in scope. Cerbos was designed for low operational overhead: no database required, lightweight container deployment, and simple policy files managed like any other config.
Developer experience
Developer experience often determines whether an auth tool will actually be adopted across your team. If it is too complex, developers will look for workarounds or implement custom code, which undermines the whole system. You should evaluate how clear the documentation is, how good the SDKs are, and whether the tool makes it easy to test and integrate locally.
The right choice is one that developers can understand quickly, integrate with their stack, and test locally without friction. I love the opinion of our Head of Solutions, Aram, who has helped hundreds of startups choose auth solutions:
“Authentication and authorization aren’t just technical decisions. They’re business decisions. You need something that’s scalable from day one, not a black box that breaks when you actually need it to work. The solution has to be easy to implement, sure, but more importantly, it needs to enable your teams to ship features without constantly hitting authorization bottlenecks. At the end of the day, if your developers can’t understand it or your ops team can’t maintain it without a PhD, you’ve chosen wrong”.
If you want a quick summary, here are the leading self hosted authentication and authorization tools covered in this guide, listed in alphabetical order.
Book a free Policy Workshop to discuss your requirements and get your first policy written by the Cerbos team
Join thousands of developers | Features and updates | 1x per month | No spam, just goodies.