Authorization Is a Domain Model, Not a Permission Table

Many authorization projects begin with a spreadsheet. Roles are listed down one side, permissions across the top, and a collection of checkmarks appears to answer the question: who can do what?

The matrix is useful, but it is not the authorization model.

It says little about the context in which a permission is valid, how a person receives a role, which organization or resource the role applies to, when access becomes active, how policy reaches an API, or what evidence remains after a decision. It also tends to combine several concepts under the convenient word “role.”

As systems grow, these missing distinctions surface as duplicated checks, oversized tokens, inconsistent interfaces, support exceptions, and policy decisions hidden inside application code.

Authorization works better when treated as a domain: a connected model of subjects, responsibilities, scopes, resources, policies, decisions, and enforcement.

A permission does not answer “may this person perform this action?” until the system also knows who the person represents, where the action applies, what resource is involved, and which policy is currently valid.

Authentication gives us a subject, not a decision

Authentication establishes or verifies an identity. Authorization evaluates whether an authenticated subject may perform a particular action in a particular context.

The distinction sounds basic, yet designs often blur it. A token contains a role name, so every service treats that name as a complete access decision. A user belongs to a department, so the interface assumes all departmental records are visible. An administrator flag appears, and policy becomes a permanent shortcut.

These shortcuts avoid modeling the questions authorization actually has to answer:

• Subject: Who or what is requesting the action?
• Action: What operation is being attempted?
• Resource: Which object, record, capability, or boundary is affected?
• Context: From which organization, assignment, channel, time, or workflow state is the action requested?
• Policy: Which version of which rule applies?
• Decision: Is the result permit, deny, conditional, or indeterminate?
• Evidence: What must be recorded to explain the outcome later?

An identity can be valid while the requested action is not. Good architecture preserves that distinction across every layer.

One word called role often hides three models

Organizations use roles to describe responsibility: branch manager, financial controller, support specialist. Software uses roles to bundle capabilities: PaymentApprover, IdentityReviewer, ReportReader. A person also acts through an assignment: manager of Branch A during a specific period.

Those are related, but they are not interchangeable.

Organizational role

This describes a person’s position or responsibility in the organization. It may come from HR or organizational systems and can influence access eligibility.

System role

This is a software concept that groups permissions or policy responsibilities. It should reflect what the system needs to enforce, not merely reproduce an organizational chart.

Contextual assignment

This connects a subject and role to a scope, time, delegation, product, customer segment, or resource set. The same person may hold the same system role in one branch and have no authority in another.

Collapsing all three into a single role string makes initial implementation easy and later behavior difficult. Keeping them explicit enables lifecycle management, delegated access, separation of duties, and auditable decisions.

Scope is where authorization becomes real

A permission without scope is frequently too broad to be useful.

“View account” might mean view any account, accounts belonging to one customer, accounts served by one branch, accounts assigned to a case, or only the account currently selected in an approved workflow. Each interpretation can use the same verb and resource name while producing a very different security boundary.

Scope can come from several places:

Scope source	Example	Design question
Organization	Company, region, branch, team	Does access include descendants or only the exact unit?
Resource relation	Owner, assignee, reviewer	What creates and ends the relationship?
Transaction	Current request or workflow	Does access survive after the workflow ends?
Delegation	Temporary responsibility	Who approved it, and when does it expire?
Attribute	Risk level, product, channel	Where is the authoritative value maintained?

Scope rules belong in the domain model because they depend on business relationships. Treating them as scattered query filters makes them difficult to inspect and almost impossible to prove complete.

Model the authorization lifecycle

Access is not created once and left unchanged. It moves through a lifecycle.

A useful model distinguishes at least:

1. Eligibility: The subject meets organizational or policy conditions for a role.
2. Assignment: A role and scope are requested or allocated.
3. Approval: Required separation-of-duty or supervisory decisions occur.
4. Activation: The assignment becomes effective and is available to decision systems.
5. Use: Services evaluate actions against the active policy and context.
6. Review: Assignments and use are examined for continued necessity.
7. Suspension or revocation: Access is disabled because conditions changed.
8. Expiry: Time-bound access ends without relying on a manual cleanup.

Each transition needs an actor, rule, timestamp, and source of truth. Without lifecycle states, teams often confuse “assigned in a database” with “effective everywhere,” especially when tokens, caches, and distributed services are involved.

Keep tokens informative, not authoritative

Tokens are valuable carriers of identity and relatively stable claims. They are poor containers for every possible access decision.

If all permissions and organizational relationships are copied into a token, several problems follow: tokens grow, revocation becomes slow, policy changes wait for refresh, and services interpret claims differently. If tokens contain too little, every request may create an expensive dependency on a central service.

The right balance depends on the system, but the design should explicitly classify information:

• Claims that identify the subject and session
• Stable context that can safely travel with the request
• Dynamic relationships that require current evaluation
• Resource attributes owned by the target domain
• Policy decisions that must be centralized or consistently distributed

The token is an input to the decision. It is not the decision itself.

Align enforcement across service and interface layers

Authorization must be enforced where protected behavior occurs—normally in the service or domain boundary. Interface behavior still matters, but for a different reason.

The interface should avoid presenting actions the current user cannot complete. It should explain missing authority when appropriate and request context explicitly when a user can act in several scopes. These choices improve usability and reduce failed requests. They do not replace server-side enforcement.

A coherent path looks like this:

Identity → active assignment → request context → policy evaluation → service enforcement → interface presentation → audit evidence

Every layer should use the same vocabulary and decision identifiers. Otherwise the interface may hide an action the service permits, or the service may deny an action the interface confidently offered.

My Authorization & Access Management case study describes how I connect organizational roles, contextual scope, tokens, service behavior, and interface visibility into one staged model.

Deny is a designed outcome

A denied request is not necessarily an error. It may be the correct result of policy. Systems should distinguish:

• unauthenticated from authenticated-but-not-authorized;
• missing context from prohibited action;
• inactive assignment from invalid resource relationship;
• policy denial from unavailable decision infrastructure.

These distinctions affect security, user guidance, support diagnosis, retry behavior, and audit evidence. They must also be communicated carefully: a response should help an authorized user recover without revealing protected information to an unauthorized one.

Questions that reveal a weak model

Before approving an authorization design, ask:

• Can the same person act in more than one organizational context?
• Can two organizational roles map to the same system responsibility?
• Can one role apply to only part of a resource set?
• Which changes must take effect immediately?
• What happens to active sessions after revocation?
• Who can assign, approve, delegate, review, and revoke access?
• Which relationships are authoritative, and how fresh must they be?
• Can a service explain why a request was permitted or denied?
• Are background jobs and service identities modeled alongside human users?
• Is every interface decision backed by enforcement at a trusted boundary?

If the answer to these questions is scattered across teams and codebases, the system has permission checks but not yet an authorization architecture.

From checkmarks to a coherent policy system

The role-permission matrix remains useful. It is a view of the model and a practical artifact for review. The mistake is treating it as the whole model.

A durable authorization architecture connects organizational meaning to software responsibility, responsibility to contextual assignment, assignment to policy, policy to service enforcement, and enforcement to understandable evidence.

That is domain design. Once it is explicit, permissions become easier to implement, safer to change, and far easier to explain.