Solution Patterns
When you decide to add identity to an AI agent, you face a small set of token-flow choices. This page describes them at a generic level, so you can compare options before mapping them to specific patterns from Identity for AI Agents.
Two Questions to Start
Most of the decisions on this page come down to two questions:
- Is the agent acting on its own, or on behalf of a user?
- If on behalf of a user, is the user actively present at the moment of the call?
The four token flows in Part A answer these questions differently. Part B covers supporting patterns that compose with whichever flow you pick.
Part A: Token Flow Patterns
The four flows differ on who the token represents and how it is obtained. Choose the one (or combination) that fits how your agent is invoked.
| Acts on behalf of | User present | Flow |
|---|---|---|
| Itself | n/a | Client Credentials Grant |
| A user | Yes | Authorization Code with OBO |
| A user | No | Backchannel Authorization (CIBA) |
| Another agent | n/a | Token Exchange |
Client Credentials Grant
When the agent acts on its own — running a scheduled task, processing a queue, monitoring a system — there is no user behind the call. The agent authenticates directly to ThunderID with its own Client ID and Client Secret and receives an access token scoped to its pre-provisioned permissions. The token identifies the agent as the subject.
This is the simplest flow and fits any agent that operates autonomously. Coverage includes nightly jobs, background workers, internal data syncs, and any agent-to-service call where no user context is needed. The trade-off is that the agent's permissions are static — assigned at provisioning and applied to every request — so any access decision that depends on user identity falls to one of the delegated flows.
This flow is built using the standard OAuth2 client_credentials grant. See Agent Authentication.
Authorization Code with OBO
When a user is present at the moment the agent acts, the agent obtains a token through a standard consent flow. The user authenticates, approves the agent's access, and ThunderID issues a token that identifies the user as the subject and the agent as the actor. Services that receive this token can enforce access based on the user's permissions while knowing the agent is the intermediary.
This is the right flow for interactive assistants, chat-driven agents, and any case where the user is at the keyboard when the agent needs delegated access. The pattern covers consent capture, scope intersection (the token never exceeds what the user can do), and revocation — the user can withdraw consent at any time.
This flow is built using OAuth2 authorization code followed by a token exchange that converts the user's token into an on-behalf-of (OBO) token carrying the agent as actor. See Agent Authentication.
Backchannel Authorization (CIBA)
When the agent needs delegated access but the user is not present — a background workflow that hits a point requiring user approval, a scheduled agent that needs to access sensitive data — there is no browser to redirect. Instead, the agent sends an authorization request through a back channel. ThunderID notifies the user on a separate device. After the user approves, ThunderID issues a delegated token to the agent.
This pattern fits long-running agents, asynchronous workflows, and any case where the user authorizes once on their phone while the agent continues on a server. The trade-off is latency — the agent must wait for the user to act — and the user must have a registered device that can receive the prompt.
ThunderID will support backchannel authorization (CIBA) for background agents that need user approval without an active browser session.
Token Exchange
When one agent delegates work to another, the parent agent exchanges its current token for a new, narrower one before handing off. The parent specifies which scopes the child agent needs and which service it will call. ThunderID validates that the requested scopes are a subset of the parent's permissions and issues a new token scoped to that subset and audience-locked to the target.
This pattern fits multi-agent workflows where each hop should receive only what it needs. The chain is preserved: the new token carries the original user as subject (if any) and an actor chain of every agent that participated. The final service can inspect the chain to understand who initiated the request and how it arrived.
This flow is built using OAuth2 token exchange (RFC 8693). See Agent Authentication.
Part B: Supporting Patterns
These compose with any flow in Part A. They are independent decisions: an autonomous reporting agent and a delegated assistant can share the same resource-server design, audience-locking strategy, and credential lifecycle.
Resource Servers and Audience Locking
A resource server in ThunderID groups related capabilities into a protected unit. Each resource server defines scopes, and every issued token is bound to a specific audience — typically the resource server's identifier. A token with data:read for resource server A cannot be used against resource server B, even if B has a scope of the same name.
Audience locking is the primary defense against token replay. When the parent agent in a chain exchanges its token, it specifies a target resource indicator, and ThunderID binds the new token to that target. If the child agent tries to use the token against a different service, the service rejects it.
Capabilities Involved
- Group related capabilities into a resource server.
- Define scopes per capability or capability group.
- Bind tokens to a specific audience via the
audclaim or resource indicator. - Reject tokens at the service edge if the audience does not match.
Scope Granularity
Scopes describe what the bearer of the token may do. The right granularity depends on how independently you want to grant and revoke access. One scope per endpoint gives maximum flexibility but multiplies management overhead. One scope per capability group is the common middle ground — coarse enough to be readable, fine enough to support meaningful separation between read-only and write access.
For agents, scope granularity also shapes downscoping during multi-agent delegation. A parent that holds a coarse analytics:* scope can downscope to analytics:read for a child; a parent that only holds analytics:read cannot widen to analytics:write no matter what it does.
Capabilities Involved
- Per-endpoint scopes for fine-grained control.
- Per-capability scopes for the common middle ground.
- Roles that bundle scopes for ergonomic assignment.
- Downscoping rules enforced at token exchange.
Delegation Chain Preservation
When multiple agents participate in a single request, every hop should be visible to the final service. The token carries the original user as subject, and each agent in the chain as a successive actor. The final service can inspect this chain to attribute the action and to enforce policies that depend on how the request arrived — for example, "only allow this action if a human user initiated the chain."
Capabilities Involved
- Subject claim identifying the originating user (if any).
- Actor chain identifying each agent in the delegation path.
- Per-hop audit log entries for traceability.
- Service-side policies that reference the chain.
Credential Lifecycle
Each agent has its own Client ID and Client Secret. These credentials need a lifecycle: issuance at registration, rotation on a schedule, and revocation when the agent is decommissioned or compromised. Because each agent is a distinct identity, revoking one agent's credentials does not affect any other agent's operation.
Capabilities Involved
- Generate credentials at registration.
- Rotate credentials on a schedule or on demand.
- Revoke immediately when an agent is decommissioned.
- Audit credential operations.
Cross-Cutting Choices
Every implementation touches these regardless of which flow you pick.
- Agent type: autonomous (own identity only), interactive (delegated, user present), hybrid (some calls autonomous, others delegated).
- Token lifetimes: short-lived access tokens with refresh, versus long-lived per-call tokens. Shorter tokens reduce blast radius if leaked; refresh tokens preserve usability.
- Observability: logging every token issuance, exchange, and validation produces the audit trail you need to investigate incidents and prove compliance.
- Storage: where the agent stores its Client Secret and any refresh tokens it holds — secrets manager, environment variable, or hardware-backed store.
Next Steps
Choose the flow that fits your agent, then see it running in Try It Out.
