JWT - Delegated Actor Claims & RFC 8693

2026-08-01

Thanks to Matthew Wasbrough, who recently brought up token delegation in a work chat and shone a light on parts of the specification I had not used prior. That conversation prompted me to take a deeper dive into how identity standards handle token claims when one entity acts on behalf of another in a system.

RFC 8693: OAuth 2.0 Token Exchange

As it turns out, this pattern is formalised in RFC 8693 (OAuth 2.0 Token Exchange). Section 4 of RFC 8693 introduces the act (actor) claim within JSON Web Tokens (JWTs).

The act claim explicitly distinguishes between impersonation and delegation:

Impersonation: A party presents a token where sub is set to the target user, but no record of the acting service exists in the token. Downstream services cannot tell that an intermediate service initiated the request.
Delegation: The primary subject (sub) remains the target user, while the act claim explicitly identifies the party authorized to act on behalf of that user.

Nested JSON Objects vs. Lists

When designing delegation chains, a common initial intuition is to reach for a flat array or list of strings or IDs (e.g. "act": ["service-a", "service-b"]). However, RFC 8693 intentionally specifies the act claim as a JSON object, not a JSON list.

To represent a multi-hop delegation chain (for instance, User → Service A → Service B), RFC 8693 uses recursive nesting of the act claim object:

{
  "sub": "user_12345",
  "iss": "https://auth.example.com",
  "aud": "https://api.internal.service",
  "act": {
    "sub": "service-b-client-id",
    "act": {
      "sub": "service-a-client-id"
    }
  }
}

Why Recursive Nesting Trumps Flat Lists

Using a nested JSON object structure rather than a simple array provides several distinct advantages:

Rich Metadata per Actor: Each level of the act object can carry its own distinct claims (such as sub, iss, client_id, or idp), rather than restricting actors to simple strings.
Unambiguous Chain of Delegation: The top-level act object identifies the immediate actor presenting the token, while deeply nested act objects represent prior upstream actors in the chain.
Standard Compliance: Downstream microservices and identity libraries compliant with RFC 8693 can automatically inspect and validate the delegation semantics without needing custom parsing logic for array elements.

Reflection & Building Trust

Reflecting on past projects, I had previously relied on what RFC 8693 defines as impersonation—setting the subject (sub) to the target user being acted on behalf of, simply because I was unaware of the act claim standard. Without explicit delegation claims, downstream services lose crucial audit context regarding which intermediate component initiated the request.

It's a great reminder of how important it is for technical experts to listen to one another and explore open standards together. Exchanging these insights elevates our shared knowledge, leading to stronger software design, clearer audit trails, and greater security and trust overall.

By Lewis Cowles