Authentik vs Keycloak shows where IdPs stop and auth begins

At a glance

What this is: This is a side-by-side comparison of Authentik and Keycloak that finds both are capable self-hosted identity providers, but they diverge on flexibility, federation depth, and operational burden.

Why it matters: For IAM practitioners, the comparison matters because IdPs that handle authentication well can still leave authorization, lifecycle, and workload access decisions underspecified across NHI, autonomous, and human identity programmes.

👉 Read Cerbos' full comparison of Authentik vs Keycloak and authorization fit

Context

Authentik and Keycloak sit in the identity provider layer, where the job is to authenticate an identity and pass trusted claims to downstream applications. That works for login, SSO, and MFA, but it does not solve the harder question of what a user, service, workload, or agent can do once access is established. When identity and authorization are treated as one problem, teams often overextend the IdP and create brittle policy logic.

The practical comparison is therefore operational, not just feature-based. Authentik leans into configurable flows, proxy mode, and support for older applications, while Keycloak leans into federation, enterprise directory integration, and platform-scale IAM patterns. For teams that want a broader reference point on how non-human identities fit into identity architecture, the Ultimate Guide to NHIs is the best starting place.

Key questions

Q: How should teams decide between Authentik and Keycloak for self-hosted identity?

A: Start with the operating model, not the feature list. Authentik usually fits teams that want flexible flows, proxy-based access, and easier adaptation for mixed applications. Keycloak usually fits teams that need federation depth, enterprise directory integration, and a more established platform model. The best choice is the one that matches your legacy footprint and the amount of operational complexity you can support.

Q: When does an identity provider stop being enough for access control?

A: An identity provider stops being enough when permissions must vary by resource, context, workload, or request path. At that point, login and token issuance still matter, but they are no longer sufficient for governing what an identity can actually do. Teams should add a dedicated authorization layer once role-based decisions become too coarse for the applications they run.

Q: What do teams get wrong about IdP-native roles and policies?

A: They often assume roles and built-in policies can scale to every authorization use case. That works for broad access decisions, but it breaks down for fine-grained checks across APIs, service accounts, and mixed application estates. The fix is not more role nesting. It is separating identity trust from decision-making and applying policies closer to the resource.

Q: How should IAM teams govern authorization for workloads and service accounts?

A: Treat workloads and service accounts as first-class identities, then define where IdP claims are enough and where policy evaluation must be externalized. That approach prevents permission logic from drifting into individual services and makes review, audit, and change control far easier. Use the IdP for trusted identity data and the policy layer for contextual enforcement.

Technical breakdown

Authentication vs authorization in self-hosted IdPs

Authentication proves who or what is signing in. Authorization decides what that identity can do after the login event, and those are separate control planes even when an IdP issues the token. Authentik and Keycloak both centralize identity proofing and token issuance, but they do not remove the need for a separate policy layer when access must vary by resource, context, workload, or request path. That separation becomes more important when applications, APIs, and service accounts all consume the same identity data in different ways.

Practical implication: keep the IdP focused on trust establishment and move fine-grained permission decisions into a dedicated authorization layer.

Proxy mode, federation, and legacy integration

Authentik’s proxy mode lets teams place an authentication layer in front of applications that were not built for modern SSO or MFA. Keycloak approaches the problem differently, with stronger emphasis on federation to external identity sources such as LDAP, Active Directory, FreeIPA, and Kerberos. In practice, the choice is about where the integration pain sits. Proxy wrapping can simplify older apps, while federation can better preserve existing enterprise directory structures and upstream identity relationships.

Practical implication: map legacy applications and directories before choosing an IdP, because the integration pattern often determines the long-term operating cost.

Why fine-grained authorization needs a separate policy engine

Both platforms offer role-based access controls and policy features, but IdP-native permissions are usually too coarse for service-level, resource-level, or context-aware decisions. Fine-grained authorization needs externalized policy evaluation so the application can ask a consistent question at runtime instead of embedding permission logic in every service. That architecture becomes especially relevant when the same identity must be evaluated across web apps, APIs, background jobs, and machine-to-machine workflows. The boundary between identity issuance and decision-making is the architecture decision that prevents policy sprawl.

Practical implication: treat the IdP as the source of identity truth and use a separate authorization layer for contextual access decisions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Authentik vs Keycloak is not an identity competition, it is a control-boundary decision. Both tools can centralize login, SSO, and MFA, but neither should be asked to solve every downstream authorization problem. The architectural mistake is treating identity proof and access decision as one layer, which usually leads to brittle policy logic inside the IdP and inconsistent enforcement across applications. Practitioners should separate authentication infrastructure from authorization governance.

Self-hosted IdPs become governance-heavy as soon as they sit in front of legacy systems. Authentik’s proxy mode and Keycloak’s federation reach both reduce integration friction, but they also widen the blast radius of misconfiguration. Once a central IdP fronts many older applications, an access model change can affect more services than the team initially expects. The practical conclusion is that integration breadth must be matched with stronger change control and review discipline.

Fine-grained authorization is the named gap this comparison exposes: IdP-level roles are not enough. Both products support role and policy features, but those controls are still too blunt for resource-specific, context-specific, and high-volume decisions. The implication is that teams need a separate policy decision point when access logic begins to vary by resource, workload, or request context.

Operational simplicity and enterprise breadth trade places, rather than one product clearly winning. Authentik tends to push complexity into flexible flows and optional scripting, while Keycloak tends to push complexity into platform weight, tuning, and upgrade management. That means the real question is not feature count but what kind of operational debt a team is willing to own. Practitioners should choose the simpler failure mode for their environment, not the bigger product checklist.

Identity governance does not end at the IdP boundary when NHIs and services are in scope. Service accounts, APIs, workloads, and emerging agentic systems all consume identity in ways that outgrow simple login-centric thinking. The broader lesson is that identity architecture must support the actor type being governed, not just the human-facing front door. Teams should design for the full path from authentication to entitlement review to policy enforcement.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves central identity stacks blind to a large part of the machine identity estate.
• That visibility gap is why 52 NHI Breaches Analysis is useful next, because it shows how identity exposure turns into operational compromise.

What this signals

Fine-grained authorization will continue to move out of IdPs and into policy engines. As identity estates grow to include service accounts, workloads, and AI-driven systems, teams will need a clearer separation between who authenticated and what was allowed to happen. The organisations that keep permission logic inside login infrastructure will accumulate policy debt that becomes hard to audit or migrate.

Identity centralization increases both control and blast radius. A self-hosted IdP can simplify SSO and MFA, but once it fronts many older applications the same design can amplify the impact of a bad flow change or federation mistake. That is why the strongest programmes treat identity platform design as a change-managed control surface, not just an implementation detail.

Runtime policy evaluation is the better fit for heterogeneous access patterns. When the same identity can act as a user, a service account, or a workload, static roles become too blunt to stay safe. Teams should expect more pressure to pair IdPs with separate authorization controls, especially where service accounts and other NHIs need context-aware decisions.

For practitioners

• Separate authentication from authorization Keep the IdP responsible for identity proofing, token issuance, and login flows, then place fine-grained policy decisions in a dedicated authorization layer so permissions stay auditable and portable across services.
• Inventory legacy integration pressure before choosing an IdP Map which applications need proxy wrapping, which directories need federation, and which access paths still depend on older protocols so the integration model does not surprise the operating team later.
• Treat flow design as infrastructure design If you adopt a flexible IdP with custom flows or scripting, put change control, testing, rollback planning, and documentation around those flows exactly as you would for application code.
• Define the authorization boundary for non-human identities Document where service accounts, workloads, and API-driven access stop relying on IdP roles and start using context-aware policy checks, especially where multiple services consume the same identity claims.

Key takeaways

• Authentik and Keycloak solve the same login problem, but they diverge sharply on operating style, federation depth, and integration burden.
• The main architectural limit is not authentication, it is authorization, because IdP-native roles rarely handle fine-grained decisions cleanly.
• Teams should choose the IdP that fits their environment, then externalize policy where access needs to stay contextual and auditable.

Key terms

• Identity Provider: An identity provider is the system that authenticates an identity and issues the claims other applications trust. In practice, it centralizes login, SSO, MFA, and federation, but it should not be confused with the full authorization stack that decides what an identity may do after sign-in.
• Fine-grained Authorization: Fine-grained authorization is access control that evaluates specific actions against specific resources using roles, attributes, policies, and context. It goes beyond broad user groups and becomes essential when applications, APIs, service accounts, and workloads all need different permissions from the same identity source.
• Proxy Mode: Proxy mode is a pattern where an identity layer sits in front of an application and enforces authentication before traffic reaches the service. It is useful for legacy apps that do not natively support modern identity protocols, but it also concentrates control and requires careful governance.
• Federation: Federation is the trust relationship that lets one identity system accept identity signals from another directory or provider. It reduces duplication and supports enterprise integration, but it also creates dependency chains that must be monitored, tested, and governed as part of the identity architecture.

Deepen your knowledge

Authentik vs Keycloak, and the boundary between authentication and authorization, are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing identity governance across human and non-human access paths, it is worth exploring.

This post draws on content published by Cerbos: Authentik vs Keycloak, with where Cerbos fits for fine-grained authorization. Read the original.