Open source auth tools expose the AuthN and AuthZ split

At a glance

What this is: This is Cerbos's guide to open source authentication and authorization tools, with the core finding that AuthN and AuthZ must be designed as separate layers rather than treated as one control.

Why it matters: IAM teams need this split because coarse access models fail quickly once humans, workloads, service accounts, and AI systems share the same environment.

Context

Open source identity stacks often blur authentication and authorization, but the governance problem is not tooling abundance. The real issue is that one control proves identity while another decides permitted action, and treating them as interchangeable creates brittle access decisions that do not scale across modern application estates.

Cerbos frames the topic through the practical reality of mixed identity environments. As applications add service accounts, workloads, APIs, and agentic systems, the separation between AuthN and AuthZ becomes a design requirement, not a preference, because least privilege can only be enforced where authorization is evaluated with enough context.

Key questions

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. Authentication belongs at login or token issuance, while authorization should evaluate whether a specific request is allowed. That split reduces brittle code, makes policy easier to audit, and prevents broad access decisions from being hidden inside sign-in logic.

Q: Why do coarse access rules break down in modern identity environments?

A: Coarse rules usually work only when the same identity and the same action apply everywhere. In modern estates, users, service accounts, workloads, APIs, and agents need different entitlements by resource and context. When access is reduced to broad groups or binary allow lists, teams lose the ability to enforce least privilege consistently.

Q: What are the signs that an authorization model has become too tightly coupled to the application code?

A: A tightly coupled model usually shows up when small policy changes require code changes, deployments, or manual edits across multiple services. Another warning sign is when authorization checks are mixed with business logic, making the code hard to test or refactor. If teams cannot upgrade policy without untangling application behavior, the design has already become too rigid.

Q: When should security teams use a dedicated policy engine for access decisions?

A: Use a dedicated policy engine when access depends on resource identity, tenant context, actor type, or other conditions that simple RBAC cannot capture. A policy engine becomes especially valuable when the same application must govern human users and non-human identities without rewriting authorization logic for each service.

Technical breakdown

Why AuthN and AuthZ fail when they are merged

Authentication confirms identity. Authorization evaluates entitlement. When teams collapse both into one layer, they usually end up with coarse allow or deny rules that cannot express resource-level context, role scope, or policy exceptions. That creates hidden coupling between login, token issuance, and permission checks, which is especially brittle in distributed systems. Open source identity stacks can reduce that complexity if each function is placed where it belongs: IdP or login service for AuthN, policy engine for AuthZ, and the application or API as the enforcement point. The architectural issue is not just separation of duties. It is separation of control planes so identity proof and access decisions can evolve independently.

Practical implication: Map AuthN and AuthZ to different services and verify that permission decisions are not embedded in login flows.

How fine-grained authorization differs from identity login

Fine-grained authorization is about deciding what a verified identity can do with a specific object, action, or context. That is fundamentally different from establishing that the identity exists and has authenticated successfully. In the article's terms, SSO, MFA, and federation belong to the AuthN side, while RBAC, ABAC, least privilege, and contextual policy belong to AuthZ. This matters because many open source tools stop at broad access rules or group membership, which is adequate for simple gateways but too coarse for application, API, workload, or service-account decisions. The right mental model is layered: prove identity once, then evaluate authorization continuously at the action boundary.

Practical implication: Use a dedicated policy layer whenever access needs to vary by resource, context, or actor type.

Why open source auth stacks still need policy externalisation

Externalising policy from application code makes authorization easier to version, test, and audit. That is valuable because hard-coded permission logic tends to spread across services, become inconsistent over time, and block scale when business rules change. The article highlights a key advantage of policy-driven systems: they let teams update access logic without redeploying every application. For enterprises, that also improves reviewability, because access intent is visible as policy rather than buried in code paths. The technical choice here is not open source versus commercial. It is whether authorization is a shared control plane or a collection of one-off implementation details.

Practical implication: Keep authorization rules out of app code so policy changes can be tested, audited, and updated centrally.

NHI Mgmt Group analysis

AuthN and AuthZ should be treated as different governance problems, not adjacent features. Authentication is about proving who or what is present. Authorization is about constraining what that identity can do after it is admitted. When teams merge the two, they usually optimise for login convenience and end up with access models that cannot express least privilege at the resource level. The implication is that IAM architecture has to separate identity proof from permission decision-making if it is going to scale.

Open source auth stacks expose the real boundary of modern IAM: identity is no longer only human. The article explicitly extends authorization to workloads, service accounts, APIs, MCP servers, and agentic AI systems, which means the control surface now spans actors with very different runtime behaviour. A single coarse access model cannot govern that mix cleanly. Practitioners should read this as evidence that policy evaluation must sit closer to action than to login.

Fine-grained authorization is becoming the control plane for least privilege. RBAC alone is enough only when access patterns are stable and simple. Once contextual decisions, multi-tenant boundaries, or application-specific resource checks enter the picture, the decision has to move into a policy engine that can express conditions and log outcomes. That shifts governance from static role assignment to continuous entitlement logic, which is where modern identity programmes are heading.

Separating AuthN from AuthZ also clarifies accountability across the stack. Identity providers, token services, reverse proxies, and policy engines are not interchangeable building blocks. Each one owns a different control objective, and trying to make one layer do everything creates ambiguity in audits, incident response, and change management. The practical conclusion is that teams should evaluate every auth component by the control it actually enforces, not by how complete the bundle appears.

From our research library:

• Software supply chain attacks were projected to cost organisations $60 billion in 2025.

What this signals

AuthN and AuthZ separation is no longer just an architecture preference: it is the only reliable way to keep login controls from becoming a stand-in for entitlement governance. As more stacks mix humans and non-human identities, the decision point has to move closer to action, not just admission.

Policy externalisation is the governance pattern that scales: teams that keep authorization out of application code gain clearer auditability, simpler change control, and less permission drift across services. That matters most when workload identity, service accounts, and agentic systems share the same environment.

For practitioners

• Separate identity proof from permission decisions Use the login, SSO, and MFA layer only for AuthN, and place resource-level and contextual decisions in a distinct authorization service.
• Externalise authorization policies from application code Keep RBAC, ABAC, and least-privilege rules in centrally managed policies so changes can be versioned, tested, and audited without redeploying apps.
• Model service accounts and workloads as first-class actors Verify that non-human identities are governed by the same policy layer as users, especially where APIs, MCP servers, and automation share permissions.
• Review coarse access rules for hidden privilege expansion Look for systems where group membership, proxy rules, or token claims are carrying authorization logic that should be evaluated against resource context instead.

Key takeaways

• Open source auth stacks create flexibility, but that flexibility only helps if authentication and authorization are separated into different control planes.
• The article's core operational message is that identity proof, token issuance, and permission evaluation solve different problems and should not be merged.
• For IAM teams, the practical test is whether least privilege can be enforced centrally across users, workloads, service accounts, and agents.

Key terms

• Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• 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.
• Policy Engine: A policy engine evaluates identity, device, and transaction data against defined rules and then automates the access decision. It is the mechanism that turns zero trust from a concept into an operational control by allowing approval, blocking, quarantine, or revocation based on risk.

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.