Authentication and authorization are drifting apart at scale

At a glance

What this is: This primer explains how authentication and authorization differ, and why modern access control is moving toward dynamic, relationship-aware enforcement.

Why it matters: IAM teams need this distinction because conflating identity verification with permission decisions creates fragile controls across human, NHI, and application access flows.

👉 Read Authzed's primer on authentication versus authorization

Context

Authentication answers who an entity is, while authorization answers what that verified entity can do. The distinction matters because access control breaks down when identity proof and permission checks are treated as the same control plane, especially in distributed systems that must govern humans, service accounts, and application-to-application access.

Authzed's framing reflects a wider IAM problem: static checks do not age well when permissions depend on relationships, context, and rapidly changing resource boundaries. For teams managing non-human identities, the challenge is not just verifying a principal but keeping authorization decisions aligned with the current state of access.

That makes this topic relevant to identity architecture, not just application design. Teams that still blur authentication and authorization often end up with revocation gaps, overbroad roles, or UI-layer controls that do not hold at runtime.

Key questions

Q: How should security teams separate authentication from authorization in modern applications?

A: Security teams should treat authentication as the step that proves identity and authorization as the step that evaluates permitted actions on specific resources. Keep those controls in separate services or layers so revocation, auditing, and policy updates can happen without changing how identity is verified. That separation reduces hidden policy drift and makes access decisions easier to test and explain.

Q: Why does relationship-based access control matter for application and NHI governance?

A: Relationship-based access control matters because many permissions are not really role-based at all. They depend on ownership, membership, hierarchy, or delegation paths, which static roles handle poorly. For non-human identities and distributed applications, modelling relationships explicitly gives you a clearer permission path, fewer overbroad grants, and a better fit between policy and runtime behaviour.

Q: What breaks when authorization decisions are cached too long?

A: When authorization state is cached too long, a service can keep allowing access after a policy change or revocation should have taken effect. That creates stale permission windows, inconsistent enforcement across services, and audit gaps when investigators try to reconstruct who could access what at a given moment. The problem is not only technical latency, but governance drift.

Q: How do identity teams know when a JWT should not carry permissions?

A: A JWT should not carry permissions when access changes frequently, revocation matters, or the same token would need to reflect different resource decisions over its lifetime. In those cases, embedding permissions in the token creates drift and delays enforcement. Use the token for identity context, then ask a live authorization system to make the final decision.

Technical breakdown

Authentication is identity proof, not permission

Authentication establishes that a request comes from a known subject by checking evidence such as passwords, passkeys, tokens, biometrics, or federated assertions. It does not decide whether the subject should be allowed to act. That decision belongs elsewhere, and when teams collapse the two steps they often embed access logic into login flows, JWTs, or front-end checks that cannot reliably enforce policy at request time. In distributed environments, the identity claim must stay stable while the permission decision remains dynamic.

Practical implication: keep identity proof and access decisions in separate layers so revocation and policy changes can take effect without redesigning authentication.

Authorization is a runtime decision, not a static role lookup

Authorization evaluates whether a verified subject may perform a specific action on a specific resource. Simple role models work only when access patterns are coarse and stable. Once permissions depend on relationships, ownership, group membership, or contextual conditions, static RBAC becomes too blunt and can either overgrant or block legitimate access. Relationship-based access control computes permissions at query time from object and subject relationships, which makes policy more expressive and closer to how applications actually work.

Practical implication: model permissions as runtime decisions tied to resource relationships, not as oversized roles that try to do every job.

ZedTokens and relationship graphs solve stale permission decisions

Modern authorization systems need consistency as well as flexibility. If a permission change is not reflected immediately, a service can continue to grant access based on stale state. Systems like SpiceDB address this by evaluating relationship tuples through a schema and using consistency tokens to avoid read-after-write gaps. The Watch API then supports downstream cache invalidation and audit visibility. That architecture matters because authorization failures are often timing failures, not just policy design failures.

Practical implication: use consistency-aware authorization so revoked or changed access does not linger after the policy update.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Authentication and authorization are separate security problems, and treating them as one creates control drift. Authentication proves who the subject is. Authorization decides whether that subject can perform the requested action on the requested resource. When programmes collapse those layers, they blur revocation, auditing, and policy ownership, which is why access failures often surface as application bugs rather than identity events. Practitioners should treat the split as an architectural boundary, not a documentation detail.

Relationship-based access control is the right mental model for systems where access depends on context, not just role. RBAC remains useful for coarse entitlement sets, but it breaks down when permission depends on object relationships, ownership, or nested hierarchies. That is especially relevant for application platforms and NHI-driven service-to-service access, where static role assignment cannot express the real access path. Practitioners should map where roles are doing relationship work they were never designed to do.

Stale authorization state is a governance problem, not only a technical defect. If permission changes do not propagate quickly, the system can continue to authorize actions that policy has already withdrawn. That failure mode is especially damaging in high-churn environments where access changes frequently and should take effect immediately. Practitioners should design authorization with consistency, cache invalidation, and auditability as first-class requirements.

Authn and authz separation becomes more important as identity expands beyond humans. Service accounts, tokens, and application identities still need proof of identity, but their permissions often change faster than human access patterns and are easier to overgeneralise. A programme that works only for human sign-in flows will miss how machine access is actually granted and enforced. Practitioners should review whether their access model still holds once non-human identities are in scope.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many access decisions are still being made against incomplete identity inventories.
• For the broader governance model, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and privilege failures that drive authorization drift.

What this signals

Relationship-first authorization will become the default expectation for systems that cannot be governed safely with flat roles. As applications, service accounts, and delegated access paths multiply, teams will need policy models that reflect who relates to what, not just who belongs to which group. The practical shift is from entitlement accumulation to query-time enforcement.

The next governance gap is not authentication strength alone, but whether permission state can be kept current across fast-changing workloads and third-party integrations. Teams should expect revocation testing, cache invalidation, and audit fidelity to matter more as identity flows become more distributed.

For a broader benchmark on non-human identity exposure, the Ultimate Guide to NHIs remains useful context because it shows how quickly machine access expands beyond what most programmes can see or govern.

For practitioners

• Separate identity proof from permission enforcement Keep authentication in the identity provider layer and authorization in a dedicated decision point. Avoid burying access rules in JWT claims, UI logic, or application code paths that cannot react cleanly to revocation.
• Model access as resource relationships Map which subjects can act on which objects and why, then express those relationships explicitly instead of expanding roles until they become unmanageable. This is especially important for shared resources, delegated access, and service-to-service calls.
• Test revocation and policy change propagation Verify that a removed entitlement stops working immediately enough for your risk tolerance. Include cache invalidation, re-check timing, and downstream service behaviour in the test plan, not just the policy definition.
• Review NHI access paths separately from human login flows Service accounts, API clients, and workloads often need different enforcement logic than end-user authentication. Validate where non-human identities authenticate, where they are authorized, and whether the same policy model is being stretched across both.

Key takeaways

• Authentication proves identity, but authorization is what actually limits action, so collapsing the two creates fragile access control.
• Static roles are too blunt for relationship-driven access patterns, especially where non-human identities and application resources interact at runtime.
• Teams should design for immediate policy propagation, because stale authorization state turns approved access changes into governance gaps.

Key terms

• Authentication: Authentication is the process of proving a subject is who it claims to be. In practical identity systems, that proof may come from passwords, passkeys, tokens, biometrics, or federated assertions. Authentication establishes identity context, but it does not decide whether the subject may act on a resource.
• Authorization: Authorization is the decision process that determines whether a verified subject can perform a specific action on a specific resource. It evaluates policy, relationships, and context at the point of access. Good authorization changes with the environment, rather than relying on a one-time sign-in decision.
• Relationship-Based Access Control: Relationship-based access control is an authorization model that grants access by evaluating how a subject relates to an object, such as ownership, membership, delegation, or hierarchy. It is better suited than flat roles for applications where permissions depend on dynamic relationships instead of fixed job functions.
• Consistency Token: A consistency token is a mechanism that helps ensure authorization checks reflect the most recent policy state. It reduces stale permission decisions after changes, revocations, or writes. In practice, it matters whenever access decisions must update quickly enough to avoid lingering entitlements.

Deepen your knowledge

Authentication and authorization separation is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment mixes human sign-in, service accounts, and application access, it is worth exploring.

This post draws on content published by Authzed: AuthN versus AuthZ, a primer on secure access. Read the original.