Relationship-based access control is exposing authN-authZ confusion

At a glance

What this is: Authzed explains why authN-style attributes often fail as an authorization model and why relationship-based access control is a better fit for fine-grained permission decisions.

Why it matters: IAM and IGA teams should treat authorization as its own governed model, because confusing identity attributes with access decisions creates brittle permissions, audit drift, and inconsistent enforcement across services.

Context

AuthN is who a subject is and authZ is what it can do, but many application stacks blur the two when permission design starts as an extension of login design. That shortcut works poorly once teams need fine-grained access control, because user attributes such as groups, scopes, and claims do not fully answer whether a subject can act on a resource.

This matters to IAM and IGA programmes because access models often outgrow the identity provider primitives they borrowed at the start. When authorization logic is scattered across application code and interpreted differently by each service, governance shifts from policy design to bug hunting and consistency management.

Relationship-based access control addresses that gap by modelling access as relationships between subjects and resources rather than as overloaded identity attributes. In practice, the governance problem becomes schema design, lifecycle consistency, and propagation of relationship changes across systems.

Key questions

Q: What breaks when authorization is skipped after authentication?

A: When authorization is skipped, any valid credential can become broad access. That creates lateral movement risk, weakens least privilege, and removes the policy boundary needed for zero trust. It also makes incident response harder because the environment cannot show which identity was allowed to perform which action.

Q: Why does relationship-based access control reduce authorization drift?

A: Because access is represented as explicit subject-resource relationships, not as overloaded identity attributes that each application interprets differently. That makes the permission model easier to reason about, easier to audit, and less dependent on whether every service agrees on what a role or claim should mean.

Q: How should IAM teams use ReBAC without losing control of access governance?

A: Use ReBAC to model who is connected to what, then place it inside a policy layer that also evaluates context, sensitivity, and lifecycle status. That keeps relationship-driven access precise without making the graph the only decision factor. The goal is not just faster authorization, but decisions that can be explained, reviewed, and revoked when relationships change.

Q: What is the operational risk if different services interpret access relationships differently?

A: You get authorization drift, where the same subject can be allowed in one service and denied in another. That creates inconsistent enforcement, hard-to-diagnose access bugs, and a governance gap between policy design and what users actually experience.

Technical breakdown

Why authN attributes break down as authZ inputs

Authentication systems usually expose attributes such as groups, roles, scopes, or claims. Those values describe facts about an identity, but they do not by themselves answer the access question, which is whether a subject may perform an action on a resource. Once teams start using attributes as permission inputs, they must define how those attributes combine, override, or imply one another. That interpretation layer is where drift begins, because every service can encode the same attribute differently. A mature authorization system needs a decision model, not just identity facts.

Practical implication: Separate access decision logic from identity attributes before those attributes are hard-coded as policy semantics.

How relationship graphs make fine-grained access decisions

Relationship-based access control represents access as graph reachability between a subject and a resource. Instead of asking whether a user has an abstract role, the system asks whether a path exists through relationships such as ownership, membership, or delegation to the required permission. This removes the need to infer meaning from attributes like admin or team member, because the permission itself can be represented directly as a relationship. The model also scales better when access changes frequently, because the graph can be updated without rewriting every application that consumes it.

Practical implication: Model permissions as explicit subject-resource relationships when access needs to change without application rewrites.

Why consistency controls matter in ReBAC

A relationship model only works if every service evaluates the same schema and reads the same relationship state. The article points to consistency mechanisms such as ZedTokens to avoid stale reads after recent writes, which is the classic mismatch between policy change and enforcement visibility. Without that consistency layer, a newly revoked or granted relationship can be interpreted differently across services, creating authorization gaps even when the model is sound. ReBAC reduces ambiguity, but it does not remove the need for lifecycle discipline, schema governance, and propagation control.

Practical implication: Treat relationship consistency and schema versioning as core governance controls, not implementation details.

NHI Mgmt Group analysis

Authorization confusion is the real governance failure, not lack of identity data. The article shows that groups, scopes, and claims are often treated as if they were sufficient answers to access questions, when they are only identity facts. That assumption breaks once permission decisions need to survive application growth, delegation, and service-by-service interpretation. IAM teams should treat authorization as a separate control plane, not as an extension of authentication metadata.

ReBAC restores a cleaner decision model because it encodes access as a relationship, not an interpretation. This matters because the question shifts from what a user is to what a subject is connected to in the resource graph. That model is easier to audit and reason about than scattered attribute logic, especially when permissions evolve over time. The practitioner takeaway is that fine-grained access works better when the permission itself is the primary object of governance.

Relationship-based access control changes the lifecycle problem from user login to relationship consistency. Once access is expressed as graph links, the operational challenge becomes keeping those links correct, current, and uniformly enforced across applications. That creates a stronger case for policy schema governance, timed revocation, and consistency controls than for more identity-provider logic. IAM and IGA teams should manage relationships as governed assets, not as incidental application data.

Conway's Law still applies, but the article shows why authorization cannot be trapped inside organisational structure. If every application must mirror the identity provider's simplest constructs, the permission model is forced to follow tool convenience rather than business reality. ReBAC reverses that pressure by letting systems reflect how people actually share resources and delegate access. The field should view this as a design correction: authorization should model work relationships, not authentication shortcuts.

ReBAC does not eliminate governance complexity, it relocates it to the place where it belongs. The hardest problems move from interpreting attributes to governing schema, relationship consistency, and revocation semantics. That is a healthier trade because the access model becomes explicit instead of implicit, but it still demands disciplined ownership. Practitioners should expect less policy ambiguity and more lifecycle rigor, not a free pass on control design.

What this signals

Authorization confusion is a governance problem, not just a modelling problem: when teams borrow login primitives to answer access questions, they create a policy layer that is too vague for audit and too brittle for change. IAM programmes need a distinct authorization model with explicit relationships and consistency rules.

ReBAC sharpens the boundary between identity and access: the subject is not the permission and the attribute is not the decision. That distinction matters for IGA because reviews, revocation, and delegation all work better when access is represented as governed relationships rather than inferred meaning.

The operational test is simple: if a permission cannot be explained as a subject-resource relationship, the model is probably depending on implicit interpretation somewhere. That is where service-by-service drift begins and where governance should focus first.

For practitioners

• Separate authentication facts from authorization rules Inventory where groups, scopes, and claims are being used as implicit access decisions, then remove that logic from application code where possible. Make the authorization model explicit so identity attributes describe the subject, while relationships describe the permission.
• Model permissions as relationships Define the core subject-resource links that actually represent access in your business, such as ownership, membership, editor, or delegate. Use those relationships as the basis for fine-grained checks instead of overloading roles to carry every rule.
• Govern schema changes like policy changes Treat relationship schema updates as controlled changes with versioning, testing, and rollback expectations. If one service interprets a permission differently from another, the authorization model will drift even when the underlying identity data is correct.
• Enforce consistency on relationship reads Verify that access decisions cannot be made on stale relationship data after grants or revocations. Where the platform supports it, use consistency tokens or equivalent controls so recent changes are visible before a decision is returned.
• Review lifecycle handling for delegated access Check whether granted relationships expire or are explicitly removed when work ends, because relationship-based models still accumulate stale access if ownership and delegation are never cleaned up.

Key takeaways

• Many access systems become fragile because they treat authentication attributes as if they were complete authorization rules.
• Relationship-based access control makes permissions easier to model by tying them to explicit subject-resource relationships.
• The hard part moves from login integration to lifecycle governance, schema consistency, and synchronized enforcement.

Key terms

• 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.
• Authority Drift: Authority drift occurs when different systems hold conflicting versions of identity data and no clear owner resolves the mismatch. It is a governance failure that leads to duplicate work, stale entitlements, and access decisions based on partial or inconsistent records.
• Relationship Schema: The structured definition of which subjects may relate to which resources, and what those relationships allow. A governed schema turns access logic into an explicit data model, which is critical for consistency, lifecycle control, and predictable revocation across applications.
• 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

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.