Notifications
Clear all
Topic starter
10/06/2026 10:55 pm
TL;DR: Authorization systems built on authentication primitives often become fragile because they treat roles, scopes, and claims as if they fully answer access questions, according to Authzed. Relationship-based access control shifts the decision to graph-based subject-resource relationships, which makes fine-grained permissions easier to reason about and harder to encode incorrectly. When access is modeled as relationships, the governance problem becomes lifecycle and consistency, not just login integration.
NHIMG editorial — based on content published by Authzed: Relationship-based access control and the authN-authZ split
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams separate authentication from authorization design?
A: Security teams should keep authentication focused on proving identity and move authorization into a dedicated policy layer that evaluates actions against resources.
Q: Why do relationship-based permissions work better than role-based permissions for complex apps?
A: Relationship-based permissions work better when access depends on ownership, delegation, inheritance, or changing collaboration patterns.
Q: What do teams get wrong when they use identity claims as access policy?
A: Teams often assume that a claim can answer the full question of whether a subject may act on a resource.
Practitioner guidance
- Separate authentication from authorization ownership Keep login, federation, and identity proofing distinct from access policy design.
- Model permissions as explicit relationships Represent ownership, membership, delegation, and viewer relationships as first-class policy objects.
- Test policy consistency after every relationship change Validate that grants and revocations are reflected consistently across check, list, and subject-resolution paths.
What's in the full article
Authzed's full article covers the operational detail this post intentionally leaves for the source:
- The authors' step-by-step explanation of how ReBAC queries traverse subject-resource relationships for access checks.
- The practical differences between RBAC, ABAC, and ReBAC when policy inheritance and delegation chains get complex.
- The architecture notes around SpiceDB schema design, consistency handling, and query types for checks and listings.
- The FAQ section's additional guidance on expiring relationships, caveats, and operational scaling concerns.
👉 Read Authzed's explanation of ReBAC and fine-grained authorization →
ReBAC and authN-authZ confusion: what IAM teams should change?
Explore further
12/06/2026 4:40 am
AuthN and authZ confusion is a governance smell, not a syntax problem. When login systems are treated as permission engines, the organisation inherits identity attributes that only describe the subject, not the action. That is a structural failure in policy design because access meaning gets compressed into claims that were never intended to carry business rules. Practitioners should treat this as a separation-of-duties issue inside the identity architecture itself.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Only 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do you know if a relationship-based access model is working?
A: A relationship-based model is working when access decisions stay consistent as relationships change, and when revocations take effect without code changes in every application. Teams should look for stable checks, clear audit trails, and reduced policy duplication across services. If policy meaning still varies by app, the model is not yet mature.
👉 Read our full editorial: Relationship-based access control is exposing authN-authZ confusion
