Notifications
Clear all
Topic starter
10/06/2026 10:55 pm
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.
NHIMG editorial — based on content published by Authzed: AuthN versus AuthZ, a primer on secure access
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Separate identity proof from permission enforcement Keep authentication in the identity provider layer and authorization in a dedicated decision point.
- 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.
- Test revocation and policy change propagation Verify that a removed entitlement stops working immediately enough for your risk tolerance.
What's in the full article
Authzed's full article covers the implementation detail this post intentionally leaves for the source:
- A deeper walkthrough of relationship-based access control schema design for application permissions
- Concrete examples of how OIDC subject claims flow into authorization checks at runtime
- Practical comparisons between RBAC, ABAC, and ReBAC for teams building fine-grained access control
👉 Read Authzed's primer on authentication versus authorization →
Authn vs authz: where access control is getting harder?
Explore further
12/06/2026 4:39 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authentication and authorization are drifting apart at scale
