TL;DR: Authentication verifies identity while authorization determines allowed actions, and Authzed argues that modern systems need to keep those layers separate as permissions grow more dynamic and relationship-driven. For IAM teams, the real shift is that static role checks and token-based shortcuts no longer hold up under scale or revocation pressure.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Authzed's blog post: Authentication confirms identity while authorization decides access, a separation that becomes harder as permissions grow more dynamic and scale-sensitive.
Why it matters: IAM teams need to keep identity proofing, policy evaluation, and runtime enforcement distinct or they will inherit revocation gaps, stale decisions, and brittle permission models.
Context
Authentication and authorization solve different problems, and conflating them becomes more expensive as access decisions move from simple role checks to relationship-aware policies. Authentication establishes who or what is making the request, while authorization determines what that identity may do with a resource.
The governance challenge is not just technical vocabulary. As applications distribute permissions across more services, teams need identity verification that stays stable and authorization logic that can change quickly without baking policy into tokens or user interfaces.
Key questions
Q: What breaks when authentication and authorization are treated as the same control?
A: Teams lose visibility into whether the real problem is identity proof or permission scope. That leads to weak remediation, because fixing login assurance does not reduce access blast radius, and tightening roles does not stop bad authentication. Mature IAM programmes separate the two so they can measure, govern, and audit them independently.
A: Organisations should use relationship-based access control when access depends on user to resource relationships that repeat across many objects, such as a project team inheriting permissions across documents or tasks. Use attribute-based access control when access is driven by resource fields or simple conditions. The right choice depends on relationship complexity, not preference.
Q: How do teams know if token-based access decisions are creating revocation risk?
A: Watch for permissions that remain valid after the underlying relationship or policy has changed, especially when a token continues to authorize actions after the user should have lost access. That is a freshness problem, and it usually means the token is carrying too much authorization logic instead of deferring to live policy evaluation.
Q: What is the difference between stable identity and current permission in access control?
A: Stable identity is the verified subject identifier that says who or what is making the request. Current permission is the real-time decision about whether that subject may do a specific action on a specific resource. Keeping those separate helps teams avoid stale access, brittle role design, and revocation gaps.
Technical breakdown
Why authentication is not authorization
Authentication proves identity. Authorization evaluates whether a verified identity can perform a specific action on a specific resource. The article’s core point is that these are different control planes, even when they are chained together at request time. In modern systems, authentication may rely on passwords, passkeys, or federated identity, while authorization depends on policy engines, relationship graphs, or role and attribute logic. Confusing them creates brittle designs, because a valid login does not mean every downstream action is permitted.
Practical implication: keep identity proofing and permission decisions in separate control layers.
Why RBAC breaks when permissions become relationship-driven
Role-based access control works when access can be expressed as a small set of stable job functions. It becomes awkward when permission depends on relationships between users, objects, teams, and contextual conditions. That is where relationship-based access control and attribute-aware evaluation become more useful, because the system can calculate access at request time rather than stuffing every possibility into a static role model. The technical shift is from coarse membership checks to explicit graph-based authorization logic.
Practical implication: model access as relationships when roles no longer describe how work is actually shared.
Why token-based shortcuts create revocation and freshness problems
JWTs and similar tokens are useful for carrying identity claims, but they are a poor substitute for live authorization when permissions can change quickly. If policy lives inside the token, revocation becomes delayed, and decisions can drift away from current state. The article points to consistency mechanisms such as ZedTokens and streaming relationship updates because authorization needs freshness as much as identity needs proof. In practice, this is the difference between a stable subject identifier and a current permission decision.
Practical implication: avoid embedding access decisions in long-lived tokens when permissions must change in real time.
NHI Mgmt Group analysis
Authentication and authorization drift apart because they solve different governance problems. Authentication is about establishing identity, while authorization is about controlling action. Once systems become distributed and relationship-driven, collapsing those layers creates policy leakage, stale access, and enforcement that cannot keep up with how work actually moves. The implication is that IAM programmes must treat identity verification and permission evaluation as distinct disciplines, not interchangeable labels.
Relationship-based access control is the right lens when roles stop describing reality. Simple RBAC models assume access can be captured in static job buckets, but modern collaboration often depends on object relationships and context. That pushes authorization into a runtime decision problem, which is why graph-based and caveated policies are gaining traction. Practitioners should expect the governing model to follow the shape of work, not the shape of the org chart.
AuthN/AuthZ separation is a control boundary, not an implementation detail. When UI checks, application code, and token claims are asked to do authorization’s job, revocation and auditability suffer. A stable identity source can feed a separate decision engine, but it should not absorb the full burden of access enforcement. Teams that blur this boundary usually create faster systems first and harder-to-govern systems later.
Dynamic authorization is becoming a core access governance requirement, not an advanced feature. The article points toward real-time, context-aware permission evaluation as systems scale and collaboration patterns multiply. That trajectory matters for IAM, IGA, and PAM teams because access cannot remain a static afterthought once resources, relationships, and revocation timelines change continuously. The practitioner conclusion is to design for live authorization from the start.
What this signals
AuthN/AuthZ separation is becoming a programme design issue, not just an application pattern. As permissions become more dynamic, teams that push authorization logic into identity tokens or front-end checks will struggle to keep revocation, auditability, and decision freshness aligned. The better governance model is a stable identity source feeding a separate policy decision layer.
Relationship-based access control deserves attention wherever collaboration is object-specific. The practical signal is simple: if access depends on who owns, shares, or administers a resource, static roles will eventually overgrant or undergrant. IAM and IGA leaders should treat that as a modelling problem, not a UI problem.
For practitioners
- Separate identity proofing from permission checks Make the identity provider responsible for authentication and a distinct policy layer responsible for authorization decisions. This keeps stable identity assertions separate from changing access rules.
- Model access as relationships where roles are too coarse Use object relations and computed permissions when team membership, ownership, or collaboration ties determine access more accurately than static roles.
- Stop encoding live permissions in long-lived tokens Treat tokens as identity carriers, not as the final source of truth for current access. Re-evaluate revocation and freshness whenever policy changes must take effect immediately.
- Add runtime checks for revocation-sensitive access Verify that policy decisions are made against current state at request time, especially for resources where sharing changes often and stale access would create exposure.
Key takeaways
- Authentication and authorization are different controls, and combining them creates brittle access governance as systems scale.
- Static roles and token shortcuts work poorly when access depends on relationships and revocation-sensitive state.
- Teams need live authorization decisions backed by stable identity proofing if they want access control to stay accurate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The article focuses on separating identity proofing from access decisions at request time. |
| Recommendation — Map authorization checks to API5-style enforcement and keep identity proofing separate from permission decisions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authentication controls and token handling are central to the article’s access boundary. |
| Recommendation — Use IA-5 to manage authenticators without letting them double as the authorization system. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about how permissions should be decided and enforced. |
| Recommendation — Apply PR.AA-05 to separate entitlement decisions from identity verification and keep access current. | ||
| NIST Zero Trust (SP 800-207) | Verify Explicitly — Verify Explicitly | The article’s access model depends on continuous verification rather than assumed trust after login. |
| Recommendation — Adopt explicit verification at request time instead of relying on authenticated session state. | ||
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.
- Relationship-Based Access: An access model where entitlements are justified by the current business relationship, such as employee, contractor, student, vendor, or service account status. In practice, the relationship defines scope, duration, ownership, and review requirements.
- Dependency Freshness: The degree to which a codebase uses current, supported upstream packages and libraries. Freshness is more than version count. It reflects how quickly teams absorb security fixes, compatibility changes, and upstream releases before known weaknesses become easy targets.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org