Authorisation Models Guide: RBAC, ABAC, ReBAC and Policy Engines

Authentication proves who someone or something is. Authorisation decides what they may do, and it is where most access problems actually live. Over-privileged users, service accounts with wildcard permissions, applications that trust any authenticated caller and APIs that check the user but not the object all come down to authorisation design. This guide explains the main access control models (RBAC, ABAC, ReBAC and policy-based access control), how they compare, how externalised authorisation and policy engines work, and how to choose and combine models for people, workloads and AI agents.

Key takeaways

• RBAC is simple and auditable but becomes coarse and bloated at scale. ABAC adds context. ReBAC fits sharing and ownership models. Policy-based (externalised) authorisation makes decisions consistent and auditable across applications.
• Most organisations should combine models: roles for coarse boundaries, attributes and relationships for fine-grained decisions.
• Externalise authorisation from application code where possible, so policy can be reviewed, tested and changed centrally.
• Always enforce object-level authorisation. Checking only that a caller is logged in is the most common API flaw.

The models

Role-based access control (RBAC)

Permissions are grouped into roles, and roles are assigned to identities. "Accounts payable clerk" can create invoices; "finance approver" can approve them.

• Strengths: easy to understand, audit and certify; well supported everywhere.
• Weaknesses: role explosion as exceptions pile up; cannot express context such as time, location, data sensitivity or ownership; tends towards over-privilege.

Attribute-based access control (ABAC)

Decisions evaluate attributes of the subject, resource, action and environment against policy. "Clinicians may read records of patients in their department during their shift from a managed device."

• Strengths: fine-grained and contextual; fewer roles; adapts as attributes change.
• Weaknesses: depends on accurate, timely attributes; policies can be hard to reason about and audit without good tooling.

Relationship-based access control (ReBAC)

Access follows relationships in a graph: a user can edit a document because they are a member of the team that owns the folder containing it.

• Strengths: natural for collaboration, multi-tenant SaaS, hierarchies and delegation; scales to large numbers of objects.
• Weaknesses: requires maintaining a relationship graph; "why does this user have access?" can be complex to answer.

Policy-based access control (PBAC) and externalised authorisation

Authorisation logic is written as policy and evaluated by a policy decision point (PDP). Applications and gateways act as policy enforcement points (PEPs), asking the PDP for decisions. PBAC can implement RBAC, ABAC and ReBAC rules together.

• Strengths: consistent decisions across applications; policy as code, versioned and tested; central audit of decisions.
• Weaknesses: adds a dependency and latency; requires integration work in each application.

Comparison

Standards and tools

• OAuth scopes express coarse delegated permissions; Rich Authorization Requests (RFC 9396) allow fine-grained authorisation details.
• OpenID AuthZEN Authorization API 1.0, approved as a Final Specification in January 2026, standardises the PEP-to-PDP interface.
• XACML is an older OASIS standard for ABAC policy.
• Open source policy languages and engines, and relationship-based authorisation systems inspired by Google's Zanzibar paper, are widely used for externalised authorisation.
• NIST SP 800-162 defines ABAC concepts.

Authorisation for non-human identities and AI agents

• Service accounts and workloads usually get roles or cloud IAM policies. Keep them per workload and least privilege, and use access analysis to remove unused permissions. See the Service Account Security Guide.
• Cloud IAM policies are a form of ABAC; use conditions (resource tags, source, time) to tighten them.
• AI agents need task-scoped, per-action decisions that combine the agent's permissions with the user it acts for. See the AI Agent Authorisation Guide.

Designing an authorisation strategy

1. Use roles for coarse entitlements aligned to job functions and applications, keeping the role catalogue small. See the Role Mining and Role Design Guide.
2. Add attributes and relationships for fine-grained, context-dependent decisions within applications.
3. Externalise where it pays off: new applications, shared APIs, regulated data and AI agent tool access.
4. Enforce object-level checks in every API, since broken object-level authorisation is the top risk in the OWASP API Security Top 10.
5. Govern the model: review roles and policies, test policy changes, and log decisions for audit.

Common failure patterns

• Hundreds of near-duplicate roles created for individual exceptions.
• Authorisation logic scattered through application code, impossible to audit.
• APIs that check authentication but not whether the caller may access the specific object.
• Wildcard permissions granted to workloads "temporarily".
• Attributes (such as department) that are stale, making ABAC decisions wrong.

Practitioner checklist

• Choose models per use case and document the rationale.
• Keep the role catalogue small; use attributes and relationships for exceptions.
• Externalise authorisation for new applications, shared APIs and AI agent tools.
• Enforce object-level authorisation on every API endpoint.
• Maintain accurate attribute and relationship data from authoritative sources.
• Version, test and review policy; log authorisation decisions.

Standards and references

• NIST SP 800-162: Guide to ABAC
• OpenID AuthZEN Authorization API 1.0
• RFC 9396: OAuth 2.0 Rich Authorization Requests
• OWASP API Security Top 10
• OWASP Authorization Cheat Sheet

Related NHI Mgmt Group resources: IAM and IGA Basics · AI Agent Authorisation Guide · Zero Trust for AI Agents · Segregation of Duties Guide