Token Exchange Needs an Actor Budget, Not Just an Audience
An access token usually answers two questions: who issued it and whom it represents. Token exchange introduces a third question that many implementations answer poorly: which intermediary acted on the represented user's behalf? RFC 8693 calls this delegation and gives the authorization server two relevant inputs, subject_token and actor_token. If a service accepts every exchanged token that has the right audience and scope, it can lose the distinction between a user acting directly and a background worker acting for that user.
The problem is easiest to see in a chain of automation. A calendar service receives a user token and exchanges it for a token that can read a document store. A workflow engine then exchanges that token again to let an export job run. Each token may have the same audience and the same read scope. The final resource server sees a valid token, but it has little evidence about the workload that requested it. If the workflow engine is compromised, its token can be used as a general user credential unless the authorization server records the actor and the resource server enforces the distinction.
RFC 8693 defines an act claim that can represent a chain of delegation. The specification also notes that a request containing only subject_token cannot express delegation in the same way as a request with an actor_token. That does not mean every token must contain an act claim. It means a design that needs delegation must decide how the actor is identified, which exchange paths are allowed, and what happens when the claim is absent. An audience check alone cannot make that decision.
Practical failures usually occur at boundaries. An internal service may validate the token's signature and aud claim, then map it to the represented user while discarding the actor chain. A queue consumer may accept the token for convenience even when its work should use a distinct client identity. A developer portal may expose token exchange to every registered client because the endpoint is described as "internal". The OAuth security best current practice in RFC 9700 makes the underlying rule clearer: an access token is tied to a resource and an action, and the resource server must check that the token was meant for that request. Delegation metadata belongs in that check when the business process depends on who acted.
A workable policy starts with an exchange inventory. For each token exchange path, record the initiating workload, the represented party, the target resource, the permitted scopes, and the maximum lifetime. Require an explicit actor identity for delegated flows. Reject an actor that the authorization server cannot map to a registered workload. Do not let a generic service token silently become a user token. If impersonation is genuinely required, give it a separate grant, a shorter lifetime, and a clear audit event.
The resource server needs a matching rule. It can require the act claim for operations that involve third-party processing, while allowing direct user tokens for ordinary interactive requests. It should log token identifier, actor subject, represented subject, audience, scope, and the business resource. Do not log the token itself. For high-risk actions, compare the actor with an allowlist for that operation instead of relying on a shared service role.
There is also a user-facing question. If a person grants an application permission to export records, that consent should describe whether the application can delegate the work to another provider. A token exchange chain that is invisible in the consent screen becomes difficult to revoke and hard to explain during an incident. Record the chain, expose it to support staff, and make revocation invalidate descendant exchanges where the authorization server supports that relationship.
Token exchange is useful because it avoids copying long-lived credentials between services. Its safety depends on preserving the reason the token exists. Audience and scope describe where and what; actor identity and exchange policy describe who is doing it. Teams that model only the first pair will eventually have a valid token with an unclear owner. Teams that give the actor a budget, with explicit grants, lifetimes, and enforcement points, can use exchange without turning every internal call into an unowned impersonation path.
