act (Actor) Claim in a JWT
act identifies the current actor acting on behalf of the subject in a delegation scenario. It is a JSON object, and nesting one act inside another records the chain of who acted through whom.
At a glance
- Claim
- act (Actor)
- Defined in
- RFC 8693 section 4.1
- Value type
- JSON object, typically containing sub and optionally iss
- Required
- Optional. Emitted by a token exchange that produced a delegation token.
- Sample value
- { "sub": "support-agent-42", "iss": "https://staff.example.com" }
- In the decoder
- Shown under Custom claims as decoded JSON, so a nested act chain stays readable rather than collapsing to one line.
In detail
Delegation and impersonation are different and act marks the difference. In impersonation the token simply claims to be the user and nothing records who is really behind it. In delegation the subject stays the user, and act names the party operating on their behalf, so a resource server can see both and log both. The distinction only exists if the claim is present, which is why RFC 8693 defines it.
The nesting rule is the part worth reading twice. The outermost act is the current actor. An act inside it is the party that actor is itself acting for, and so on down the chain, ordered most recent first. That keeps the whole history in one claim rather than in a list, and lets a resource server look at only the top level when it does not care about the earlier hops.
The value is an object, and the useful field in it is sub. Where the actor comes from a different issuer than the subject, an iss inside the act object says so, and that pair should be read the same way as any other subject: unique within its own issuer only. Nothing prevents an actor's identifier from colliding with a completely unrelated subject at another provider.
In the decoder act shows up under Custom claims rendered as JSON, which matters more here than for flat claims: a nested chain is unreadable as a single line and legible as an indented object. The tool does not explain the claim by name, since only the seven RFC 7519 claims get that treatment, but the payload panel does highlight the structure so the nesting is visible at a glance.
Examples
{
"iss": "https://auth.example.com",
"sub": "8f14e45fceea167a5a36dedd4bea2543",
"act": { "sub": "support-agent-42" }
}The token still speaks for the customer. The support agent is recorded as the party acting.
{
"sub": "8f14e45fceea167a5a36dedd4bea2543",
"act": {
"sub": "billing-service",
"act": { "sub": "support-agent-42" }
}
}The billing service is acting now, on behalf of the agent, who is acting on behalf of the customer.
Things that catch people out
- Logging only sub in a delegated request. The audit trail then shows the customer doing something a staff member actually did.
- Reading the innermost act as the current actor. The order is most recent first, so the current actor is the outermost one.
- Assuming act implies authorization. Whether that actor was allowed to act is asserted by may_act on the original token, not by act on this one.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →may_act (Authorized Actor) Claim in a JWT
The may_act claim states which party may act on behalf of the subject. How it gates a token exchange, how it pairs with act, and what the decoder shows.
sub (Subject) Claim in a JWT
The sub claim says who the token is about. Why it is only unique within one issuer, what pairwise subjects change, and how the decoder shows it.
scope Claim in a JWT Access Token
The scope claim carries the granted OAuth scopes inside an access token. Why it is one space delimited string, how to check it, and what the decoder shows.
cnf (Confirmation) Claim in a JWT
The cnf claim binds a token to a key its holder must prove. How mTLS and DPoP use it, why it stops replay of a stolen token, and decoder limits.
email Claim in an OpenID Connect ID Token
The email claim carries the end user's email address. Why it must not be used as an account key, what scope returns it, and what the decoder shows.
email_verified Claim in an OpenID Connect ID Token
The email_verified claim says whether the provider verified the address. Why account linking depends on it, the string true trap, and decoder behaviour.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server