2026-09-08 · 6 min read · Rahul Chitturi
- jwt
- oauth
- authorization
A delegated token can describe both the resource owner and the service acting for that owner. If an API treats every subject as the immediate caller, audit records and authorization checks can attribute work to the wrong principal.
Token exchange profiles may add actor or delegation claims, but their meaning depends on the issuer's documented contract. Decoding a nested object does not establish that the delegation is trusted.
Name each principal and trust boundary
Record the issuer, subject, actor, audience, client, scopes, token type, and exchange path. Decide which identity owns the data, which service performs the action, and which policy constrains the combination.
- Validate the exchanged token as a new token
- Require its audience to identify the receiving API
- Constrain accepted issuers and token-exchange profiles
- Do not copy arbitrary upstream claims into a new token
Authorize the relationship, not one claim
A valid actor claim does not prove that actor may act for every subject. Enforce delegation rules, scopes, tenant boundaries, and resource policy together, then record both identities in a privacy-conscious audit event.
Keep service credentials, user grants, and refresh credentials separate. Bound delegation lifetime and depth so a chain cannot expand privilege or become impossible to revoke.
Build synthetic claim fixtures
Use the JWT tool to inspect disposable tokens, JSON formatter for nested claim types, diff for exchange outputs, timestamp converter for lifetimes, and URL tool for issuer and audience identifiers. Browser decoding is not verification.
Test missing and malformed actors, wrong audiences, tenant mismatches, nested delegation, expired grants, revoked users, key rotation, direct service calls, and complete audit attribution.