Notifications
Clear all
Topic starter
10/06/2026 10:56 pm
TL;DR: Authentik and Keycloak both centralize login, SSO, and MFA, but they differ in operating model, legacy integration, and how much complexity teams accept before adding a separate authorization layer, according to Cerbos. The real decision is not which IdP has more features, but where authentication ends and fine-grained access control must begin.
NHIMG editorial — based on content published by Cerbos: Authentik vs Keycloak, with where Cerbos fits for fine-grained authorization
Questions worth separating out
Q: How should teams decide between Authentik and Keycloak for self-hosted identity?
A: Start with the operating model, not the feature list.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Authentik deployment trade-offs for proxy mode, custom flows, and remote access support.
- Keycloak federation and clustering considerations for enterprise and legacy identity estates.
- Authorization patterns that separate IdP-issued identity claims from resource-level policy decisions.
- Operational guidance on when to keep roles in the IdP and when to move them into a dedicated policy layer.
👉 Read Cerbos' full comparison of Authentik vs Keycloak and authorization fit →
Authentik vs Keycloak: where identity providers stop short?
Explore further
12/06/2026 4:41 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authentik vs Keycloak shows where IdPs stop and auth begins
