If roles describe who someone is, and capabilities describe what they can do, context determines whether an action should be allowed in a given moment.
This is where authorization starts to get subtle - and where many systems begin to break down.
A simple example
Imagine a user who is allowed to approve invoices.
That might be true in general, but not in every situation.
They may only be allowed to approve invoices:
- for their own organization
- below a certain amount
- in a specific state
- when acting on their own behalf
Nothing about the user's role has changed. Their capabilities haven't changed either. What changed is the situation in which the decision is being made.
That surrounding information - relationships, attributes, and state - is what we mean by context.
What "context" refers to
In authorization, context is the set of facts that accompany a request but aren't part of identity or permission definitions.
It often includes:
- which tenant or organization the request applies to
- which resource is being accessed
- relationships between the actor and the resource
- relevant attributes of the request or resource
- whether access is temporary or delegated
These aren't permissions. They describe the conditions under which a decision is evaluated.
Why context doesn't fit into roles
Roles are meant to be stable. They're assigned deliberately and change infrequently. Context, by contrast, can change from one request to the next.
When systems try to encode contextual rules into roles, friction appears. Roles fragment, exceptions accumulate, and naming becomes awkward. Over time, roles stop expressing intent and start reflecting edge cases.
This is usually where authorization begins to feel brittle - not because the system is large, but because the abstraction no longer fits the problem.
Context as input, not structure
A more durable approach is to treat context as input to authorization rather than something embedded in its structure.
In this framing, a decision evaluates:
- who is acting
- what action they want to perform
- which resource is involved
- and what contextual facts are true
The logic stays stable while the inputs vary.
Instead of creating new roles or special cases, the same rules can be evaluated under different conditions. Expressiveness comes from richer inputs, not more structure.
Why this changes how systems scale
Once context is treated as a first-class input, complexity shifts in a healthier direction.
New features don't require redefining roles. New constraints don't require exceptions. New workflows don't force structural changes to the authorization model.
Behavior emerges from evaluation rather than accumulation.
Systems become easier to reason about, easier to test, and easier to extend over time.
Bringing the pieces together
Across this series, a pattern emerges:
- Roles describe who someone is
- Capabilities describe what actions exist
- Context determines when those actions are allowed
Each addresses a different dimension of the problem. Trouble starts when one is asked to do the work of another.
When context is explicit, authorization stops being a pile of special cases and starts to resemble a coherent system.
Context isn't something you assign or hardcode - it's something you evaluate.
Treating it that way shifts authorization from accumulating rules to expressing intent clearly and consistently.
