Authelia vs Authentik: what self-hosted IAM teams need to know

At a glance

What this is: This is a comparison of two self-hosted identity layers, and the key finding is that they solve similar login problems with very different scope and governance depth.

Why it matters: It matters because IAM teams can easily overestimate what gateway-style SSO tools cover, leaving authorization, lifecycle, and policy decisions outside the control plane.

👉 Read Cerbos's comparison of Authelia and Authentik for self-hosted identity

Context

Authelia and Authentik both sit in front of applications that do not have strong native identity support, but they solve only part of the identity problem. They centralise login, MFA, and SSO for self-hosted environments, which means the real question is not whether users can get in, but how much identity governance is actually being handled at the edge.

For IAM teams, that distinction matters because authentication at the gateway is not the same as policy enforcement across apps, APIs, and workloads. A tool can reduce password sprawl and improve access consistency while still leaving fine-grained authorization and lifecycle control outside its scope.

The practical decision is whether a lightweight access gateway is enough, or whether the organisation needs a broader identity provider with protocol coverage, custom flows, and operational overhead. That is a governance choice, not just a deployment choice.

Key questions

Q: How should security teams decide between a lightweight gateway and a full identity provider for self-hosted apps?

A: Start with the control boundary you actually need. If the goal is consistent login and MFA in front of apps, a gateway may be enough. If you need multi-protocol federation, custom flows, and broader identity operations, a full identity provider is more appropriate. The decision should follow governance depth, not feature count.

Q: Why do gateway-based SSO tools still leave governance gaps in IAM programmes?

A: Because they mainly solve entry control. They can centralise authentication, but they do not automatically create fine-grained authorization, lifecycle review, or downstream policy enforcement. Teams often stop at the sign-in layer and assume access is governed end to end, which is where the gap begins.

Q: What do teams get wrong about proxy mode in self-hosted identity setups?

A: They often assume proxy mode replaces native authorization design. In reality, proxy mode helps applications without SSO by placing a decision point in front of them, but it does not determine what users can do after login. If permissions differ inside the application, a separate policy layer is still required.

Q: Should organisations add a separate authorization layer alongside Authelia or Authentik?

A: Yes, whenever access decisions need to vary by resource, role, context, or workflow. Authentication tools confirm identity at the door, but they do not manage every access decision inside the estate. A separate policy decision layer keeps login control and authorization control from becoming one fragile system.

Technical breakdown

Forward-auth gateway vs identity provider scope

Authelia is designed as a forward-auth gateway, which means it intercepts requests before they reach an application and applies a login decision at the edge. Authentik goes further and behaves like a full identity provider, issuing and brokering identity across multiple protocols such as OIDC, OAuth2, SAML, and LDAP. The architectural difference is not cosmetic. A gateway can standardise entry, but an IdP becomes part of the organisation's identity fabric and carries broader operational and governance responsibility.

Practical implication: choose the narrower gateway model only when you are confident that deeper identity governance is handled elsewhere.

MFA, WebAuthn, and passkeys in self-hosted identity

Both tools support stronger authentication controls, including MFA and WebAuthn, which helps close the gap left by app-by-app login. In practice, this improves assurance at the sign-in point, but it does not automatically create stronger authorization or lifecycle discipline. Authentication proves who or what entered the control plane. It does not determine what the subject can do after login, nor does it define review, revocation, or policy drift management across downstream systems.

Practical implication: treat MFA support as an entry control, not as evidence that the whole access model is secure.

Why proxy mode does not equal fine-grained authorization

Proxy mode lets these tools sit in front of applications that lack native SSO support, which is useful for legacy or self-hosted software. But proxying traffic only creates a decision point at ingress. It does not create resource-level policy logic inside the application, nor does it replace a policy decision point for contextual authorization. That is why a gateway can reduce login sprawl while still leaving privilege decisions hardcoded or scattered across apps.

Practical implication: add separate authorization controls when users need different rights after authentication, not just a common login page.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication consolidation is not the same as identity governance. Authelia and Authentik both reduce login fragmentation, but that is only one layer of the control stack. Organisations often treat centralised sign-in as proof of maturity when the deeper problems are authorization consistency, reviewability, and revocation across the application estate. The practitioner conclusion is simple: login unification is a control improvement, not a full governance model.

Entry-point identity controls create a false sense of completeness. A gateway or IdP can make access look tidier while leaving policies scattered downstream in apps, APIs, and operational tools. That means teams may have strong MFA at the front door and still lack real least-privilege enforcement behind it. The practitioner conclusion is to evaluate where decisions are actually made, not just where users authenticate.

Self-hosted identity tools shift operational burden rather than remove it. Authentik's broader protocol support and admin features expand flexibility, but they also expand the amount of identity policy that must be maintained and audited. Authelia's smaller footprint reduces that burden, but with correspondingly less governance depth. The practitioner conclusion is to align tool ambition with the team's ability to run it responsibly.

Fine-grained authorization must remain a separate discipline. Neither product is positioned as a resource-level policy engine, which means organisations that need context-aware decisions across apps and services still need a distinct authorization layer. That boundary matters because authentication and authorization fail differently, and conflating them weakens both. The practitioner conclusion is to separate login control from policy control in the operating model.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That fragmentation and behaviour gap make it harder to sustain a clean identity boundary, which is why the broader control picture belongs in Ultimate Guide to NHIs.

What this signals

Credential and policy fragmentation usually shows up as operational drift before it becomes a security incident. When identity controls are split across login gateways, app rules, and separate policy systems, teams lose a coherent view of entitlement changes and review outcomes. That is the point where governance starts depending on human memory instead of control design.

For programmes that are already operating self-hosted identity tooling, the next maturity step is not adding more login convenience. It is clarifying which controls belong to authentication, which belong to authorization, and which belong to lifecycle governance, then instrumenting those boundaries in a way auditors can follow.

For practitioners

• Map identity responsibilities before choosing a tool Document which controls must be handled at login, which must be handled inside applications, and which must be covered by a separate policy layer. If the tool only solves entry control, do not treat it as an authorization platform.
• Test for authorization drift behind the gateway Review whether application permissions, admin functions, and support workflows still rely on embedded logic after sign-in. If rights differ materially after authentication, the gateway has not solved the core access problem.
• Choose protocol breadth only when you will operate it Use the broader IdP model only if your team can support custom flows, protocol maintenance, and policy lifecycle management. A larger identity surface creates more places for misconfiguration and review debt.
• Pair access entry controls with separate policy decisions Where applications, APIs, or self-hosted services need different access outcomes, add a dedicated policy decision point instead of extending gateway rules beyond their intended role. That keeps authentication and authorization boundaries clear.

Key takeaways

• Authelia and Authentik solve a similar login problem, but they occupy different places in the identity architecture and should not be treated as interchangeable governance layers.
• Centralised authentication improves consistency, but it does not remove the need for separate authorization and lifecycle controls behind the login wall.
• The right choice depends on how much identity policy your team can operate and audit, not on which tool exposes more features.

Key terms

• Forward-auth Gateway: A forward-auth gateway sits in front of an application and checks whether a user is allowed through before the request reaches the service. It improves access consistency for apps without native SSO, but it does not replace application-level authorization or lifecycle governance.
• Identity Provider: An identity provider is the system that authenticates users and brokers identity to multiple applications and protocols. In practice, it becomes a central control point for sign-in, federation, and policy flows, which also makes its configuration and governance more operationally important.
• Policy Decision Point: A policy decision point is a separate control that evaluates access rules outside the application code and returns an allow or deny decision. It matters when login and authorization must be distinct, especially across apps, APIs, and workloads with different access requirements.

Deepen your knowledge

Authelia, Authentik, and the boundary between authentication and authorization are practical topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a self-hosted identity programme from the same starting point, it is worth exploring.

This post draws on content published by Cerbos: Authelia and Authentik comparison for self-hosted identity and access. Read the original.