Authentik vs Keycloak shows where IdPs stop and auth begins

At a glance

What this is: This compares Authentik and Keycloak as self-hosted identity providers and shows that both stop at authentication and coarse policy, not fine-grained authorization.

Why it matters: IAM teams need to separate login control from permission decisions so they do not overload the IdP with contextual access logic across apps, APIs, workloads, and service accounts.

Context

Authentik and Keycloak are both identity providers, but that label hides an important governance boundary. They can centralize login, single sign-on, multi-factor authentication, and standards-based identity exchange, yet neither is designed to replace a dedicated authorization layer when access decisions become contextual and resource-specific.

The practical question for identity programmes is not which platform has more features. It is where authentication ends, where policy logic begins, and how much operational complexity the team is prepared to own in the self-hosted identity stack.

Key questions

Q: How should teams decide where authentication ends and authorization begins?

A: Teams should draw the line at the point where access becomes contextual, resource-specific, or workload-specific. The IdP should establish trusted identity and issue claims, while a separate authorization layer should decide what the subject may do with each resource, API, or service. That separation reduces policy sprawl and makes audits easier.

Q: Why do self-hosted IdPs become brittle when they absorb permission logic?

A: Because authentication and authorization change for different reasons and on different cadences. When role checks, resource rules, and context logic live inside the IdP, teams end up coupling login infrastructure to every application-specific policy change. That creates configuration drift, slows upgrades, and makes access decisions harder to explain and review.

Q: What are the main trade-offs between flexible flows and enterprise federation?

A: Flexible flows help teams adapt login behaviour, proxy around older applications, and tailor access to local conditions. Enterprise federation helps teams integrate directories, reuse existing identity infrastructure, and standardize across larger environments. The trade-off is operational: flexibility usually increases design complexity, while federation depth usually increases platform weight.

Q: How should organisations decide when to add a separate authorization layer after authentication?

A: Add a separate authorization layer when roles alone cannot express tenant boundaries, resource ownership, service-to-service access, or context-sensitive decisions. Authentication tells you who the principal is. Authorization answers what that principal may do right now. Separating those concerns improves auditability, makes policy easier to test, and keeps access rules out of application code.

Technical breakdown

Identity provider scope: where authentication ends

An identity provider creates and verifies identities so applications can trust a login event and receive claims through standards such as OIDC, OAuth2, SAML, and LDAP. Authentik and Keycloak both operate in that layer. They can centralize SSO, MFA, and federation, but the decision they return is still fundamentally about who authenticated, not what that subject may do inside each application or resource boundary.

Practical implication: Treat the IdP as the source of trusted identity assertions, then move resource-level permission logic elsewhere.

Operating model differences shape deployment risk

Authentik is workflow-oriented, with proxy mode, customizable flows, and support for reverse proxy enforcement around applications that lack native SSO. Keycloak is enterprise-oriented, with federation, clustering, and deep directory integration that suit heavier IAM estates. Those differences matter because identity platforms are not only security controls, they are also long-lived operational systems that teams must tune, extend, and recover.

Practical implication: Match the platform to the operational model your team can sustain, not just the features it exposes.

Authorization needs a separate policy layer

Both platforms offer some role-based or resource-based access controls, but those controls remain coarse when compared with fine-grained authorization that depends on user, service, workload, context, and action. Once access decisions must vary by resource, environment, or request context, the IdP is no longer the right place to calculate them. A dedicated policy decision layer keeps identity proof and permission logic from becoming entangled.

Practical implication: Externalize fine-grained authorization before IdP policy sprawl turns every application into its own access rules engine.

NHI Mgmt Group analysis

IdPs centralize identity, but they do not close the authorization gap. Authentik and Keycloak both solve the same authentication problem and both remain bounded by that scope. Once teams start using IdP policy features as a substitute for application-level authorization, the model becomes brittle because identity proof and permission logic have different lifecycles and different audit needs. The practitioner implication is to keep the boundary explicit.

Workflow flexibility is a governance decision, not just an admin preference. Authentik's proxy mode and custom flows reduce friction in mixed application estates, while Keycloak's federation and enterprise patterns reduce friction in legacy-heavy environments. Those strengths also create design commitments that are hard to unwind later. The implication is that flow design should be treated as infrastructure design, with change control and ownership from day one.

Fine-grained access control belongs outside the IdP. Authentication can tell a service that a subject is known, but it cannot safely answer every context-dependent permission question at the point of use. When teams blur that line, they create authorization sprawl inside the identity tier itself. The implication is to use IdP-issued identity as input, not as the final access decision.

IdP selection is now an architecture choice, not a login choice. The comparison between Authentik and Keycloak is really about operating model, federation depth, and how much policy complexity should live in the identity layer. That means identity architecture teams need to evaluate downstream authorization patterns before standardizing on either platform. The implication is to decide the permission model first, then choose the IdP around it.

From our research library:

• The average worker in a typical enterprise holds 96,000 entitlements, and 38% of IdP accounts are dormant, according to Veza's 2026 State of Identity and Access Report.

What this signals

Identity providers are increasingly being asked to do too much. The moment teams use the IdP as both trust anchor and policy engine, the architecture starts mixing authentication state with authorization semantics. That is manageable in small deployments, but it becomes a governance problem as soon as multiple applications, services, and workloads depend on the same identity tier.

Policy separation is the real scaling decision. Organisations should expect their IdP choice to shape how quickly they outgrow coarse RBAC and how painful future permission changes become. The earlier a team externalizes contextual authorization, the less likely it is to rebuild access logic piecemeal across applications.

For practitioners

• Define the authentication-authorisation boundary Document which decisions belong to the IdP and which must be made by a separate policy layer, especially for service, workload, and API access.
• Assess legacy integration requirements early Map existing LDAP, Active Directory, FreeIPA, Kerberos, proxy-based protection, and remote access needs before choosing the self-hosted IdP.
• Design flows as long-lived infrastructure Review custom authentication flows, stages, and proxy behaviour as maintainable system components, not one-off admin settings.
• Separate role logic from fine-grained policy Use the IdP for identity assertions and reserve contextual decisions for an external policy engine when resources, actions, or environments vary.

Key takeaways

• Authentik and Keycloak solve the login problem, but they do not by themselves solve fine-grained authorization across modern application estates.
• The operational difference is not feature count alone. It is whether your team can sustain flexible workflow design or heavier enterprise federation.
• The clean architecture pattern is to use the IdP for identity assertions and a separate policy layer for contextual access decisions.

Key terms

• Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
• Federation entity: A federation entity is an organisation or technical participant that publishes metadata describing its keys, endpoints, and capabilities. It is the unit of participation inside the federation, and it can be an identity provider, relying party, wallet provider, or AI agent acting on behalf of a system.
• Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.