Authorization

Authorization is determining what an authenticated actor is allowed to do. AuthBoundry evaluates authorization decisions based on policies, delegations, and capabilities.

The Authorization Decision

When your application receives a request:

  1. Application verifies authentication (identity provider)
  2. Application creates a session
  3. Application asks AuthBoundry: "Is this principal allowed to perform this capability?"
  4. AuthBoundry evaluates policies and delegations
  5. AuthBoundry returns: ALLOW or DENY (with evidence)

Deny by Default

The fundamental principle: If a policy does not explicitly allow an action, it is denied.

This prevents accidental escalation.

Example

Policy: user_alice can perform invoice.read

RequestDecisionReason
invoice.readALLOWExplicitly granted by policy
invoice.refundDENYNot in policy
invoice.deleteDENYNot in policy

Policy Evaluation

AuthBoundry evaluates policies in order:

  1. Is the principal valid and authenticated?
  2. Does a matching policy grant this capability?
  3. Is the policy still active (not expired)?
  4. Is there a delegation that grants this capability?
  5. Decision: ALLOW or DENY

Multiple Policies

A principal can have multiple policies. Authorization checks all applicable policies.

Example

Policy 1: alice can [invoice.read] Policy 2: alice can [document.edit] Policy 3: alice can [api.write]

Alice can perform any of these capabilities:

  • invoice.read → ALLOW (Policy 1)
  • document.edit → ALLOW (Policy 2)
  • api.write → ALLOW (Policy 3)
  • invoice.delete → DENY (no policy)

Delegations

Delegations grant temporary authority. If alice can perform invoice.refund and delegates it to bob, bob can also perform invoice.refund (until the delegation expires).

Example

Alice's policy: [invoice.read, invoice.refund] Alice delegates invoice.refund to Bob (expires in 24h)

During the delegation:

  • alice.invoice.refund → ALLOW (from policy)
  • bob.invoice.refund → ALLOW (from delegation)
  • bob.invoice.read → DENY (not delegated)

Explicit Capabilities

Capabilities are explicit and enumerable. There is no wildcard matching.

If a policy grants invoice.*, it does NOT grant individual capabilities. Each capability must be explicitly listed.

Tenant Isolation

Authorization is evaluated per-tenant. A principal in Tenant A cannot access resources in Tenant B.

This is enforced at the boundary, not at the policy level.

Evidence & Audit

Every authorization decision produces evidence:

  • principal_id: Who requested it
  • capability: What they requested
  • decision: ALLOW or DENY
  • reason: Which policy or delegation caused this decision
  • timestamp: When the decision was made

Evidence is immutable and queryable. Use it for auditing and compliance.

Fail-Closed Behavior

If AuthBoundry cannot evaluate a decision (e.g., service is down), the request is denied.

This prevents accidental authorization leaks.

Next Steps