Authorization Architecture: RBAC, ABAC, and Permissions

Authorization architecture becomes a product decision when permissions cross module boundaries. An application may begin with a few roles and protected pages, then expand into workspaces, billing, administrative controls, reports, automation, and APIs. At that point, a permission check is no longer just a question of whether a person sees a button. It is a rule about who may perform a specific operation on a particular resource, under which conditions, and where that rule must be enforced.

I think the most damaging design mistake is treating a role, a navigation item, and a server-side grant as if they were the same thing. Authentication establishes an identity. Authorization determines whether that identity is permitted to act. A menu can reflect the decision for usability, but it cannot provide the security boundary. An authenticated user with a valid session may still have no right to read another organization’s invoice or update a restricted field.

In this guide, I develop an authorization architecture for modular digital platforms that separates policy ownership, decision-making, and enforcement. I examine role-based access control, attribute-based access control, and relationship-based access control, then use a hypothetical multi-tenant billing platform to turn business rules into an auditable permission matrix. The central argument is simple: the quality of the permission model matters, but the consistency of its enforcement across APIs, services, jobs, and data paths matters just as much.

Decision Brief: Authorization Architecture as a System Contract

The risk: Separate modules can interpret the same user’s authority differently, particularly when tenant membership, resource ownership, and state changes are involved.

The design principle: Define the subject, action, resource, and trusted context for each protected operation; use a shared policy vocabulary and enforce the decision at every relevant boundary.

The trade-off: Centralized policy evaluation improves consistency but can introduce latency and availability dependencies. Local enforcement reduces some dependencies but can operate on stale information.

Evidence boundary: This is a research-backed architecture and illustrative permission model. It is not a report of a completed penetration test or an assessment of a named production deployment.

Authentication, Authorization, and Interface Permissions

The OWASP Authorization Cheat Sheet distinguishes identity verification from access decisions. A signed-in user is not necessarily authorized to perform every action exposed by the application. An identity can belong to several organizations, hold different responsibilities in each, and lose access without losing its authenticated session.

That is why authorization architecture must begin with a precise question: may this subject perform this action on this resource under the verified conditions? A request to read an invoice cannot be approved merely because the requester has a role labeled admin. The service needs to know which tenant owns the invoice, whether the requester is authorized in that tenant, and whether the operation is allowed on this resource.

Why Hiding Controls Is Not Policy Enforcement

Removing a menu item can improve an interface by showing only relevant capabilities. It does not protect an API. Users can call endpoints without using the interface, alter browser-side code, or send a request through an integration. The server cannot infer permission from a button having been visible at some earlier point.

A reliable authorization architecture allows the client to present a server-derived capability view for usability while keeping authoritative access checks on trusted execution paths. If a permission is revoked after a page loads, a previously visible action must not become an enduring grant.

Separate Identity, Role, Membership, and Permission

The distinctions are operational, not just semantic. A developer can audit a capability, revoke a membership, or change a policy without changing the identity itself. This also gives product and security teams a common vocabulary instead of treating every navigation role as a separate security model.

RBAC, ABAC, and ReBAC in Authorization Architecture

Role-based access control (RBAC), attribute-based access control (ABAC), and relationship-based access control (ReBAC) represent different inputs to an access decision. The best approach often combines them, but only when the underlying product rules justify the complexity. A model with more expressiveness is not automatically more secure if it depends on untrusted or stale data.

Role-Based Access Control: Stable Responsibilities

RBAC assigns capabilities to roles and then associates identities with those roles. A billing operator might create invoices, an analyst might view permitted reports, and a tenant administrator might manage billing configuration. It works well when responsibility boundaries are stable, capability groups are understandable, and the permission set does not change for every individual resource.

The limitation appears when a global role is asked to encode tenant membership, project participation, approval limits, and document status. Teams sometimes respond by creating dozens of roles for combinations of these attributes. The result is role proliferation: many labels, little clarity about why an individual action is allowed.

Good authorization architecture can retain RBAC for broad responsibility while evaluating resource ownership and current state separately. I would preserve a small, meaningful role set rather than letting role names become a substitute for business policy.

Attribute-Based Access Control: Evaluate Context

ABAC makes decisions from attributes of the subject, resource, requested action, and environment. NIST SP 800-162 describes how policies use these attributes to determine permitted operations. An invoice approval can depend on the requester’s limit, the invoice status, and current workspace membership, not simply whether the requester possesses a global role.

That expressiveness brings ownership requirements. Each attribute must have an authoritative source, a defined meaning, and a freshness expectation. A browser-provided tenant label or an outdated membership cache cannot become a trusted fact by appearing in a structured policy request. Authorization architecture fails when policy syntax is consistent but source data is not.

Relationship-Based Access Control: Follow Valid Connections

ReBAC expresses permission through relationships. A person may view a document because they belong to a project, which belongs to a workspace, which owns that document. This can be more natural than assigning a separate role for every shared project or file. The architecture must still specify which relationship implies which operation and whether access is inherited.

Relationship graphs can become complex when membership is revoked or access is delegated. Teams must examine graph traversal, propagation delay, and the difference between a connection that exists and a grant that should follow from it. ReBAC can complement ABAC: project membership establishes the scope, while document state determines whether editing is allowed.

Decision Matrix: Which Model Fits the Requirement?

My recommendation is to start from the decision the business actually needs and work backward to a model. Do not introduce a relationship engine to solve a problem that a membership check already describes, and do not force complex context-sensitive decisions into a global administrator role.

Policy Decision Points and Enforcement Boundaries

Authorization architecture needs an explicit separation between deciding and enforcing access. A policy decision point (PDP) evaluates trusted inputs against rules. A policy enforcement point (PEP) blocks or permits the attempted operation based on an applicable result. NIST SP 800-207 formalizes these ideas in zero trust architecture; application-level authorization can use the distinction without pretending to implement every aspect of a zero trust system.

Policy Decision Point: Know the Inputs

The PDP should receive a subject identity, the requested action, a specific resource reference, and the verified context necessary to evaluate the policy. It may query an authoritative membership system, resource service, or policy store. Its contract should distinguish an explicit denial from an incomplete or failed evaluation rather than treating unavailable data as permission.

An authorization architecture becomes auditable when teams can explain which data source established each important fact. If an invoice belongs to Tenant B, that ownership should come from trusted resource data. A URL parameter may say which invoice the user requested, but it should never be allowed to establish which tenant owns it.

Policy Enforcement Point: Protect the Action

A gateway can validate a session and reject broadly prohibited operations, but it often cannot tell whether a particular invoice belongs to the requester. Domain services must therefore enforce resource-specific decisions. Data storage can add defense in depth where appropriate, but a database restriction is not a substitute for defining correct application capabilities.

In an authorization architecture with multiple modules, a shared policy engine does not protect a data path until each relevant service actually enforces its result. If a report exporter omits the check, centralizing policy definitions has not solved the exposure. The OWASP guidance on authorization decisions and output handling makes this especially relevant to direct object reads, lists, searches, counts, exports, and other data releases.

Local or Remote Evaluation?

Local policy evaluation can reduce a network hop and preserve operation during some service outages, but it raises questions about policy versions and data freshness. Remote policy evaluation can improve central governance while adding latency and availability dependencies. Neither deployment style is automatically correct.

For authorization architecture, I would document whether a protected action can tolerate an old positive decision, how revocation invalidates it, and what happens if the evaluator or a required attribute source is unreachable. OWASP’s policy distribution guidance recommends treating ownership, distribution, and activation as explicit engineering concerns.

Deny by Default and Fail Closed

Deny by default means an operation needs a valid grant. Fail closed means a protected action should not become permitted simply because the system failed to obtain an acceptable decision. These choices can reduce availability in a failure scenario, so a mature platform needs controlled errors, monitoring, recovery, and a deliberate policy for any bounded exception.

Least privilege also has a lifecycle. A time-limited role, a changed organization membership, or a revoked project link can alter the answer after the browser has loaded its controls. Enforcement should use an appropriately current source of authority for the operation’s sensitivity.

Worked Example: Multi-Tenant Authorization

Consider a hypothetical B2B billing platform with customer workspaces, invoices, reports, and approvals. A user can belong to more than one workspace and can hold different capabilities in each. This is an illustrative engineering example, not a description of a client deployment or a completed security audit.

The authorization architecture for this platform needs to distinguish roles from tenant membership, invoice ownership, field visibility, and the invoice’s current state. A support agent might view a limited customer summary but not restricted payment data. A billing operator might create drafts but not approve finalized invoices. An analyst might view only the invoices belonging to workspaces where their membership is current.

Illustrative Permission Matrix

The value of a permission matrix is that it converts vague job descriptions into concrete expectations. It should identify denied paths as carefully as successful ones. An authenticated tenant administrator still needs explicit authorization for the particular operation, resource, and tenant.

The Decision Contract

The following record is a conceptual explanation, not the actual input and output format of a deployed policy engine. A production implementation would validate inputs against authoritative sources and separate the request from the returned decision.

{
  "subject": {"id": "example-user", "tenant": "tenant-a", "capabilities": ["invoice.read", "invoice.create"]},
  "action": "invoice.approve",
  "resource": {"id": "example-invoice", "tenant": "tenant-a", "status": "finalized"},
  "decision": {"effect": "DENY", "reason": "ACTION_NOT_PERMITTED"}
}

The record is denied despite matching tenant identifiers because the actor lacks approval permission and the invoice state disallows the operation. In a real authorization architecture, either constraint could be independently decisive. This matters because membership is necessary for many operations but rarely sufficient for all of them.

Tenant Boundaries in Search, Exports, and Workers

Even a correct direct-object check can be bypassed indirectly if list queries, search indexes, analytics totals, or bulk exports return data from unauthorized workspaces. The OWASP Multi-Tenant Security Cheat Sheet recommends verified tenant context and consistent isolation across storage, caching, and application paths.

A background worker is also an enforcement boundary. A queued message containing a tenant ID does not prove its producer had authority to export tenant data. Service identities need their own permission scope, and the system should define whether revocation affects queued or running work. Otherwise an asynchronous path becomes an exception nobody intended.

Three API Authorization Failures to Test Separately

The OWASP API Security Top 10 distinguishes broken object-level authorization, broken function-level authorization, and broken object-property-level authorization. These are different threat classes. In authorization architecture, each one should produce distinct test cases and protections.

Broken Object-Level Authorization

A user can legitimately call an invoice-read endpoint but may not read an invoice owned by a different tenant. Changing an object identifier should not change the answer without a corresponding valid relationship. Random identifiers make guessing harder; they do not provide authorization.

Broken Function-Level Authorization

A user who can view invoices may still lack permission to approve, delete, or export them. A hidden administration button is not a protected function. An attacker or misconfigured client can construct a direct API request, so the server needs an enforceable capability rule for the action itself.

Broken Object-Property Authorization

A subject may be allowed to read an invoice summary but not restricted payment fields. Returning a full record and hiding fields in the frontend leaks information. The server must shape readable fields and writable properties according to the policy before serialization or mutation. Read and update grants should not be assumed equivalent.

These cases show why authorization architecture cannot be reduced to one isAdmin check. The operation, resource, and exposed properties may each need a separate decision, particularly when objects cross module or tenant boundaries.

Authorization Testing: Turn Rules Into Negative Tests

The OWASP Authorization Testing Automation Cheat Sheet recommends deriving tests from an access matrix rather than testing only the application’s normal UI journey. I would use positive tests to prove legitimate tasks work, then negative tests to confirm restricted paths do not release data or create side effects.

Unit tests can verify policy decisions, but integration tests must also confirm enforcement. A controller may receive DENY and nevertheless write data before returning an error; a query may apply tenant filters to records but not to aggregate counts. Authorization testing should examine outputs and side effects, not only HTTP status codes.

A durable authorization architecture makes such test cases part of the feature contract. When a team adds an export, background job, administrative action, or sensitive field, it should update the permission matrix and the tests that protect that boundary. This is how policy remains connected to product development rather than becoming an isolated security document.

Trade-Offs: Policy Consistency, Latency, and Revocation

A global decision service offers central governance, but can become a runtime dependency for every protected action. Locally evaluated policy avoids that network dependency but raises questions about versioning and stale attributes. Resource services can enforce precise ownership checks yet drift if each team invents its own capability vocabulary.

I would choose an authorization architecture by documenting the highest-risk decisions first. Financial exports, destructive administration, and cross-tenant data access deserve stronger freshness and enforcement guarantees than a UI hint that merely hides an unavailable action. That distinction lets teams make explicit trade-offs without pretending all authorization checks have the same availability and latency needs.

For sensitive operations, a missing or invalid policy result should not become an implicit allowance. Deny-by-default behavior must be supported by operational recovery, meaningful logs, and clear error handling. Permission changes should also be observable: a system needs to know when a new policy revision has actually reached its evaluators, not merely when someone published it.

Write the Decision Down

Architecture decisions about policy ownership, caching, tenant boundaries, and revocation should be documented along with rejected alternatives and review triggers. In my related article on architecture decision records, I explain why a decision’s context and conditions matter as much as its initial outcome.

For authorization architecture, a useful ADR records who owns membership data, how resource ownership is verified, which components enforce decisions, what a failed evaluation means, and how the team tests alternate access paths. A change in collaboration features or tenant relationships then becomes an explicit reason to reconsider the policy model.

Evidence, Method, and Limits

This article synthesizes OWASP and NIST guidance into an implementation-neutral design approach. The billing matrix, JSON record, and proposed regression cases are illustrative artifacts. No live deployment was assessed, no authorization benchmark was measured, and no penetration test was performed for this publication. The proposed controls still need code review and integration testing in any real system.

Some products require more than the approach described here. Offline applications, delegated machine identities, highly dynamic resource graphs, and strict revocation guarantees can introduce additional state and trust constraints. A central engine is not automatically secure, and a modular monolith is not automatically insecure. I would judge the implementation by the correctness of its decisions and boundaries, not by the sophistication of its components.

How I Would Review an Existing Product

I would begin with a sensitive workflow, such as exporting a customer’s invoices. Trace the identity through the API, resource lookup, permission decision, data query, serializer, and background processing path. Then ask which alternate route could return the same information without passing through the intended enforcement boundary.

This approach is more informative than counting roles in a database. Authorization architecture works when every protected operation has a documented rule, trusted inputs, a defined enforcement location, and negative tests that reflect the business boundary. The design also needs maintainers who can explain and update those rules when the product evolves.

My software architecture and digital product development resource explores the broader relationship between module boundaries, product decisions, and engineering governance. Authorization is one particularly sensitive example of those architectural responsibilities.

Frequently Asked Questions

Is RBAC enough for a multi-tenant SaaS product?

Sometimes, if broad roles are combined with explicit tenant and resource checks. It is not sufficient when the role alone cannot express relationship-specific or contextual permission rules. Test the actual operation rather than deciding from a model label.

Does every service need a separate authorization engine?

No. Services that expose protected functionality need effective enforcement, but they may share a policy definition or decision service. A shared engine does not remove each service’s responsibility to enforce the result on the actual data and operations it owns.

Can a frontend permission check ever replace a server-side rule?

No. The interface may hide actions or show capability hints, but browser code and requests can be changed. The trusted service must validate the protected operation independently of what the client displayed.

How should a system handle policy-service failure?

Protected actions should not be allowed merely because a valid policy decision could not be obtained. Define a failure policy, monitoring, and recovery path, and ensure any cached decisions respect appropriate freshness and security requirements.

What is the first useful authorization test?

Start with a valid request, then repeat the same action using an identity with insufficient authority or a resource in another tenant. Verify not only the response code but also that protected data was not disclosed and the forbidden side effect did not occur.

Conclusion: Architecture Matters at Every Permission Boundary

Authorization architecture is not a role-management screen and it is not a menu-filtering rule. It is the contract between identity, business permission, resource ownership, policy evaluation, and enforcement. RBAC, ABAC, and ReBAC are tools for expressing that contract; none of them is a shortcut around correct data boundaries.

I would evaluate a platform by asking whether its rules remain correct when the product adds new modules, exports, service identities, and relationships. A clear authorization architecture lets teams see who owns each decision, what evidence the decision requires, where it is enforced, and how a failing case will be detected. That is a stronger foundation than relying on a growing collection of isolated role checks.

Find related analysis in the Software Development Articles collection.

Connect and Explore My Work

I share perspectives on software architecture, product design, technical decisions, and digital strategy across several channels. For professional discussion, find me on LinkedIn, X, and Threads. For my public technical work and design portfolio, explore GitHub and Behance.