Notifications
Clear all
Topic starter
10/06/2026 11:46 pm
TL;DR: Open-source authentication and authorization tools make it easier to assemble modern IAM stacks, but the core decision still comes down to separating AuthN from AuthZ, matching each control to the right layer, and avoiding coarse-grained access models that cannot scale, according to Cerbos. The operational choice is no longer whether to add identity tooling, but whether your architecture can enforce least privilege across users, workloads, service accounts, and agentic systems.
NHIMG editorial — based on content published by Cerbos: Open source authentication and authorization tools for modern stacks
Questions worth separating out
Q: How should teams separate authentication from authorization in modern IAM stacks?
A: Teams should separate the control that proves identity from the control that decides access.
Q: When does role-based access control stop being enough?
A: RBAC stops being enough when access depends on resource, tenant, request context, or workload type rather than a fixed user group.
Q: How can security teams govern service accounts and workloads without overgranting access?
A: They should apply the same identity governance discipline used for users, but with policy rules written for machines.
Practitioner guidance
- Separate authentication from authorization in your reference architecture Document which component proves identity, which component issues tokens, and which component makes permission decisions.
- Adopt fine grained policy evaluation for non-human access Use resource-level and context-aware rules for service accounts, workloads, and agentic systems instead of relying only on broad roles.
- Test the handoff between federation, tokens, and policy Validate the full request path across reverse proxies, IdPs, token services, and authorization engines.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Tool-by-tool feature comparisons across the 13 open source auth options, including where each fits in the stack.
- Community feedback on deployment complexity, operational overhead, and the trade-offs between lightweight and full-stack approaches.
- Product-specific notes on federation, proxy mode, token issuance, and policy enforcement that help with implementation decisions.
- Practical selection framework for matching authentication, authorization, and identity broker roles to your environment.
👉 Read Cerbos' guide to the top open source authentication and authorization tools →
Open source auth stacks: what IAM teams need to separate now?
Explore further
12/06/2026 6:06 am
Open source auth tooling is really an architecture decision about control boundaries. The article shows that teams are not choosing a single login product, they are assembling a layered identity stack from components with different responsibilities. That distinction matters because authentication, authorization, federation, and token issuance fail differently and demand different governance. Practitioners should treat stack composition as part of the security model, not just an implementation detail.
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 means many teams cannot confidently verify who or what still has active machine access.
A question worth separating out:
Q: What is the difference between an identity provider and a policy engine?
A: An identity provider establishes and brokers identity, often through login, federation, and token issuance. A policy engine decides whether a request should be allowed after identity is known. Teams need both when they want strong authentication and precise authorization, because one does not replace the other.
👉 Read our full editorial: Open source auth tools expose the AuthN and AuthZ split
