A built-in primitive assumes the authorization system owns the user concept and expects a fixed identity shape. Modelling users as subjects treats them like any other object in the graph, which lets developers represent different account types and relationships directly. The second approach is more adaptable across diverse identity providers and application designs.
Why the Difference Matters in Authorization Design
A built-in primitive treats the user as something the authorization engine already understands, with a fixed structure and a narrow set of expected relationships. Modelling users as subjects in the authorization graph makes the user just one node type among others, so the system can express richer account forms, delegated relationships, and cross-system identity context without forcing everything into one rigid schema.
That distinction changes more than data modelling. It determines whether the platform can evolve with multiple identity providers, support mixed human and machine populations, and preserve authorization logic when the underlying account model changes. A graph-based subject model is usually the better fit when identity shape is not uniform across the application estate.
For teams building around account and entitlement diversity, the practical question is whether the authorization layer should own the user abstraction or merely reference it. The answer affects how easily you can model federated identities, linked accounts, delegated access, and policy evaluation across domains.
What You Gain by Modelling Users as Subjects
When users are represented as subjects in the authorization graph, the model can capture relationships instead of hiding them behind a fixed primitive. That lets you represent parent-child account structures, external collaborators, service-linked access, and other real-world variations without creating separate authorization code paths for each one.
This approach is also easier to extend when authorization depends on more than a single user record. If the decision needs to consider group membership, account origin, organisational relationship, or delegated trust, those edges belong naturally in the graph. The result is usually clearer policy logic and less brittle application code.
- Better fit for heterogeneous identities: different account types can coexist without forcing a single user shape.
- Richer policy expression: relationships become first-class inputs to authorization decisions.
- Less coupling: the application can change its identity source without redesigning the whole authorization model.
That flexibility is especially useful when authorization must survive migration between identity providers or support multiple authentication front ends. It also aligns with the broader idea that access decisions should be driven by subject relationships, not by assumptions embedded in a single user object.
Where Built-In Primitives Still Make Sense
A built-in user primitive can be appropriate when the product truly has one canonical identity shape and the authorization layer is tightly coupled to it. In smaller systems, that can reduce implementation effort and keep policy evaluation straightforward. The trade-off is that the primitive becomes a constraint the moment identity complexity grows.
The failure mode is not usually obvious at first. Teams start with one account type, then add partner users, service-linked access, delegated administration, or federated identities, and the primitive no longer captures the actual authorization subject cleanly. At that point, engineers often add ad hoc exceptions, which makes the model harder to reason about than a subject-based graph would have been from the start.
In practice, the choice is about schema rigidity versus expressive power. If the authorization model must track real relationships across account types, modelling users as subjects is more durable. If the environment is intentionally simple and unlikely to diversify, a built-in primitive may be sufficient for a time.
Risk and Threat Considerations
Rigid user primitives can hide important relationship data, which increases the chance of mis-scoped access, brittle exception handling, and authorization drift as the environment changes. A subject-based graph reduces that pressure by making account relationships explicit, which is important when access decisions need to reflect federated, delegated, or cross-system identity patterns.
Failure mechanism: the system assumes one fixed user shape, then compensates for new account types with manual overrides, duplicated logic, or partial mappings that weaken authorization consistency.
Impact: access reviews, policy enforcement, and auditability become harder to trust, and the gap between intended and actual access can grow as identity sources and account relationships multiply.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Model and Subject Representation | Graph subject modelling directly affects how non-human and human identities are represented. |
| NHI-02 — Lifecycle and Ownership | Flexible subject modelling supports varied identity sources and account ownership changes. | |
| NHI-03 — Access and Privilege Governance | Authorization graphs need explicit subjects to express relationship-driven access decisions. | |
| Recommendation — Model users and non-human actors as explicit subjects when access depends on relationship-aware authorization. Track identity ownership and lifecycle separately from a fixed user primitive. Express least-privilege decisions through subject relationships rather than hard-coded user assumptions. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | This question is about how identities are represented for authorization decisions. |
| Recommendation — Align subject modelling with access-control requirements so policies remain consistent as identity sources change. | ||
| OWASP Agentic AI Top 10 | A2 — Identity and Access | Subject-based modelling also matters where autonomous or delegated actors participate in authorization. |
| Recommendation — Represent each actor subject explicitly when authorization depends on delegated or tool-enabled access. | ||
Practitioner Guidance
What to verify: confirm whether your authorization decisions depend only on a single human-user record or on relationships such as delegation, federation, shared ownership, or account provenance. If relationships matter, model them explicitly rather than encoding them as exceptions.
Decision rule: if the platform must support more than one identity source, or if account relationships influence access, choose a subject-based model early. Reserve a built-in primitive for cases where the identity shape is stable, narrow, and unlikely to become relationship-heavy.
Practitioner takeaway: the most durable authorization model is the one that reflects the real decision context, not the simplest user abstraction available at implementation time.
Related resources from NHI Mgmt Group
- What is the difference between identity management and authorization management?
- What is the difference between access requests and operation approvals in application authorization?
- What is the difference between strong consistency and ad hoc consistency in authorization systems?
- What is the difference between attack surface management and NHI governance?
