may_act (Authorized Actor) Claim in a JWT

may_act and act are the two halves of one mechanism and they sit on different tokens. may_act travels on the subject's own token and says who is allowed to act for that subject. act appears on the token produced afterwards and says who actually is. Confusing the two produces an authorization server that records delegation without ever deciding whether it was permitted.

The check happens at the exchange. A client presents the subject token and asks for a delegation token naming an actor. The authorization server compares the requested actor against may_act on the subject token, and refuses the exchange when they do not match. Because the constraint rides inside a signed token, it survives being passed between services without needing a shared policy lookup.

That makes it useful for narrowly scoped support access. A ticket handling system can hand a support agent a token whose may_act names that specific agent, so nobody else can exchange it, and the permission expires with the token rather than lingering in a role assignment somebody forgets to remove. The narrower the value, the smaller the window.

The decoder shows may_act under Custom claims as JSON. It cannot evaluate it, since deciding whether an exchange is permitted is the authorization server's job and needs both tokens plus policy. What the tool is good for is confirming which actor a subject token actually authorizes, which is usually the question when an exchange is being refused and the request looks correct.