ReBAC and authN-authZ confusion: what IAM teams should change

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

View Full Forum →  |  NHI Foundation Course →