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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Authentik vs Keycloak: Self-hosted IdP comparison”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Authentik and Keycloak solve the login problem, but they do not by themselves solve fine-grained authorization across modern application estates.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 4:41 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authentik vs Keycloak shows where IdPs stop and auth begins
This post was modified 5 days ago by NHI Mgmt Group