Open source auth tools expose the AuthN and AuthZ split

At a glance

What this is: This guide surveys open-source authentication and authorization tools and argues that teams must separate identity proofing from permission enforcement.

Why it matters: For IAM practitioners, the practical issue is whether their stack can govern human access, NHI workloads, and agentic systems without collapsing authentication and authorization into one brittle control plane.

👉 Read Cerbos' guide to the top open source authentication and authorization tools

Context

Authentication and authorization solve different problems. Authentication establishes who or what is making a request, while authorization decides what that identity can do once it is inside the system. When teams blur those boundaries, they usually end up with coarse-grained access, fragile integrations, or permission logic that cannot keep pace with workloads, service accounts, and agentic AI.

This matters because the identity surface is no longer limited to users. Open-source stacks now have to support human login flows, API-facing workload identities, and policy enforcement for machine-driven execution paths. That makes the real question architectural: which component proves identity, which component authorises actions, and how consistently those controls hold across the stack.

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: 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. At that point, broad roles create over-permissioning or endless exceptions. Fine grained policy enforcement is the better model because it keeps access decisions aligned to the actual request.

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. That means scoping permissions to the specific service, environment, and action, then reviewing them regularly for drift. The goal is to stop treating machine identity as a permanent exception to least privilege.

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.

Technical breakdown

AuthN vs AuthZ in open source IAM stacks

Authentication answers the question of who or what is requesting access. Authorization answers what that identity may do after it is authenticated. In open-source identity stacks, the two are often separated across different tools because a single product may be strong at login, token issuance, federation, or policy evaluation, but not all of them at once. That separation becomes especially important in mixed environments where reverse proxies, IdPs, token services, and policy engines each own a slice of the request path. A clean architecture keeps proof of identity independent from permission decisions.

Practical implication: map every tool to either identity proof or policy enforcement before you decide how it fits the stack.

Why fine grained authorization matters more than broad roles

Role-based access control is often enough for simple systems, but it breaks down when access has to vary by tenant, resource, time, request context, or workload type. Fine grained authorization adds those conditions so the same identity can be allowed one action and denied another depending on policy. That matters for APIs, service accounts, and agentic workloads because their access patterns are more dynamic than a standard user role model. When authorization stays coarse, teams start encoding business logic in application code, which is harder to test, audit, and change safely.

Practical implication: use contextual policy evaluation where permission needs depend on resource, environment, or workload state.

Open source auth tools as stack components, not substitutes

The tools in this category do not all solve the same problem. Some act as identity providers, some broker federation, some issue tokens, and some evaluate authorization policy. That means teams should not compare them as if they were interchangeable products. The better way to evaluate them is by control plane role, operational burden, and how well they fit existing systems such as Kubernetes, reverse proxies, databases, or external IdPs. Open source gives flexibility, but it also makes architecture discipline mandatory because gaps are easy to create between components.

Practical implication: choose each tool for the control layer it actually owns, then test the handoffs between layers.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Fine grained authorization is the control that prevents identity from becoming overbroad access. A role model can be sufficient until the system has tenants, workloads, or context-sensitive actions that cannot be expressed cleanly in broad groups. Once that happens, the real risk is not login failure, but permission drift and policy sprawl. Practitioners should judge every auth stack by whether it can enforce least privilege at request time, not just prove identity at sign-in.

Machine and agent access make the AuthN/AuthZ split operationally unavoidable. Human identity flows can sometimes tolerate looser coupling, but non-human identities often need policy decisions that change by system, workload, or runtime context. That is why the separation between identity proof and permission evaluation becomes more important as service accounts and AI-driven systems multiply. Practitioners should design for heterogeneous actors, not assume a user-centric model scales unchanged.

Open source adoption does not reduce governance requirements, it shifts them onto the team. Self-hosted identity components increase control over deployment and data, but they also increase responsibility for integration, policy design, auditability, and lifecycle management. The mature stance is to treat open source as an enabler of control-plane precision, not as an excuse to leave control ownership ambiguous. Practitioners should verify who owns every decision path before standardising on a tool.

From our research:

• 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.
• For a wider view of why machine identity governance has become a board-level issue, see Ultimate Guide to NHIs , Why NHI Security Matters Now.

What this signals

Identity boundary drift is the practical risk this guide exposes. As open-source stacks become more modular, teams can accidentally split identity proof, token handling, and policy enforcement across tools without clear ownership. The result is not just complexity, but governance gaps where access becomes broader than intended and harder to recertify.

The direction of travel is clear: organisations are moving from login-centric IAM to request-centric authorization models that need to work for humans, workloads, and non-human identities alike. That puts pressure on lifecycle controls, policy versioning, and auditability because permission decisions now matter at runtime, not only at sign-in.

For teams planning stack changes, the key signal is whether a tool can preserve least privilege when identity is not human. If it cannot express resource-level decisions cleanly, the programme will eventually push those rules into application code or manual exceptions, which is where governance starts to erode.

For practitioners

• Separate authentication from authorization in your reference architecture Document which component proves identity, which component issues tokens, and which component makes permission decisions. If one tool is doing two jobs, record the boundary explicitly so future changes do not collapse policy into login logic.
• 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. That keeps least privilege enforceable when requests vary by tenant, request context, or execution path.
• Test the handoff between federation, tokens, and policy Validate the full request path across reverse proxies, IdPs, token services, and authorization engines. Look for gaps where a trusted login creates permissions that are broader than the downstream policy layer intended.
• Review lifecycle controls for every identity type Make sure joiner-mover-leaver, offboarding, and recertification processes cover humans, service accounts, and AI-driven identities separately. A clean authentication stack is not enough if stale entitlements remain active after business or system change.

Key takeaways

• Open-source IAM stacks only work cleanly when authentication and authorization are treated as separate control problems.
• Coarse roles are insufficient once workloads, service accounts, and agentic systems need context-aware permission decisions.
• The main governance risk is not lack of login capability, but overbroad access created by poor control-plane boundaries.

Key terms

• Authentication: Authentication is the process of proving who or what is making a request. In modern identity systems it may involve passwords, MFA, certificates, or tokens, but the purpose stays the same. It establishes identity, not permission, and should be separated from the policy layer that decides access.
• Authorization: Authorization is the decision process that determines whether an authenticated identity can perform a specific action on a specific resource. It can be coarse or fine grained, but mature programmes push those decisions into policy rather than application code. That keeps access control auditable, testable, and easier to change.
• Fine Grained Authorization: Fine grained authorization means access is evaluated using detailed context such as resource, role, tenant, environment, or request attributes. It is the right model when broad groups are too blunt to express real business rules. For non-human identities, it is often the difference between controlled access and accidental overpermissioning.
• Identity Provider: An identity provider is the system that establishes and brokers identity, usually by handling login, federation, and token issuance. It does not need to make every permission decision itself, and in many architectures it should not. Its job is to prove identity reliably so downstream controls can make better access decisions.

Deepen your knowledge

Open source authentication and authorization architecture is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are separating identity proof from policy enforcement across humans, workloads, and agents, it is worth exploring.

This post draws on content published by Cerbos: Open source authentication and authorization tools for modern stacks. Read the original.