Tensions in Practice: Shared service reach in tension with caller-bound authority¶
Document service · acting for a caller
A caller asks a service for document A. The service itself can read A and B. If the next step acts with the service’s broad credential, the authority reaching the documents can exceed the caller’s request. Carrying the caller’s permitted scope downstream narrows that reach, but adds delegation data and enforcement obligations. Knowing who contacted the service is not the same as deciding whose authority it should use.
Support the service’s assigned work
Give a shared service the reach needed to perform its own authorized function.
Preserve caller boundaries
Keep a request made for one caller from silently inheriting unrelated service authority.
Why these aims pull against each other
A service can be both an authenticated actor and a deputy for someone else. Using its standing grant is simpler, but does not by itself preserve the originator’s permitted scope.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Use the service grant
Execute under the service’s own authority over both example documents.
- What it protects
- A service-owned operation can proceed without constructing a separate scoped delegation for each request.
- What it costs
- The caller’s narrower reach is not enforced merely by using this credential; an induced or erroneous request may use the service’s wider grant.
- When it fits
- Fits service-owned work whose full scope is independently authorized. It does not fit arbitrary caller-supplied operations just because the caller authenticated.
Illustration note: The two-document authority graph is editorial. It shows possible reach, not an exploit or a claim that every service credential is inappropriate.
Carry caller scope
Carry verifiable originating-principal and resource-scope information to the executing service, and enforce it there.
- What it protects
- The illustrated request can reach A without receiving a grant to B.
- What it costs
- Scoped credentials must be issued, carried, checked, and kept appropriately fresh; omitted enforcement or ambient authority can defeat the intended boundary.
- When it fits
- Fits work performed on behalf of callers with different allowed resources, when all relevant paths correctly bind execution to the represented scope.
Illustration note: This illustrates a contract supported by Signed Delegation Token, not a complete secure protocol. Possession, audience, revocation, and every enforcement path still matter.
What this illustration does—and does not—establish
Access Control: Authentication-Authorization Conflation and Confused Deputies supplies the principal/deputy distinction. The related token mechanism makes the carried origin and scope concrete; the service-owned baseline remains conditional.
- Authentication establishes an identity; it does not decide which actor’s authority governs this request.
- A signature alone does not make the issuer’s decision appropriate or exclude other authority paths.
- The example assumes A and B are separately protectable resources and does not certify a real access-control system.
Source entries
Access Control
Access Control: Authentication-Authorization Conflation and Confused Deputies supplies the conflict examined here.
Authentication-Authorization Conflation and Confused Deputies
- T4: Authentication-Authorization Conflation and Confused Deputies. A principal authenticated with one identity performs work on behalf of another, under the authority of a third; the reference monitor must determine which identity's authority governs. Confused-deputy attacks (Hardy 1988) exploit this; OAuth's scopes, token delegation, and workload identity (SPIFFE) address parts but introduce their own complexity.
Signed Delegation Token
Supplies portable principal and scope claims and their issuance/enforcement costs.
How it works
- Carry it with the request. Each hop forwards the token unchanged; the delegation moves with the work instead of being re-asserted by intermediaries. - Verify before acting. The executing deputy checks the signature, confirms freshness, and evaluates the request against the token's scope — offline, without a callback — refusing anything the token does not cover.
Tuning parameters
- Scope granularity — a broad audience versus a token minted for one action on one resource. Narrow scope contains misuse but multiplies issuance and can leak intent into the token's structure.