When your AI agent needs to book a hotel, approve a transaction, or access member-only data, you're managing authentication, authorization, and transaction approval across different trust levels. OAuth 2.0 provides the protocol to handle these tasks securely.
This checklist outlines the requirements for securing AI agents that operate across trust boundaries, from public access to authenticated sessions to explicit user approval. It focuses on OAuth 2.0, token exchange, and [Client-Initiated Back-Channel Communication Authentication (CIBA)](https://openid.net/specs/openid-client-initiated-Back-Channel Communication-authentication-core-1_0.html), with specific checkpoints for your implementation.
Prerequisites
Before you start, confirm:
- Identity provider configured. Ensure you have an authorization server supporting OAuth 2.0, token exchange (RFC 8693), and CIBA.
- Agent registration complete. Register your AI agent as an OAuth client with appropriate redirect URIs and grant types.
- Policy Decision Point available. Have a policy engine to evaluate tool or API calls against authorization rules.
- Backend APIs defined. Each protected resource should have a distinct audience identifier and scope namespace.
OAuth 2.0 Configuration
1. Register the AI agent as an OAuth 2.0 client
Configure your authorization server with the agent's client credentials, redirect URIs, and allowed grant types (Authorization Code Flow with PKCE).
✓ Good looks like: Client metadata includes client_id, redirect_uris, token_endpoint_auth_method, and grant_types such as authorization_code and urn:ietf:params:oauth:grant-type:token-exchange.
2. Define resource audiences and scopes
Create distinct audience identifiers for each protected surface (e.g., myapp-mcp for the agent-facing layer, myapp-api for backend services). Define granular scopes for each capability.
✓ Good looks like: The MCP layer has audience myapp-mcp with scope mcp:member_rates. The backend API has audience myapp-api with scope api:member_rates. No scope appears in both namespaces.
3. Implement Authorization Code Flow with PKCE
When the agent accesses protected functionality, redirect the user to your authorization server. Use Proof Key for Code Exchange to prevent authorization code interception.
✓ Good looks like: Your agent generates a code_verifier, hashes it to create code_challenge, includes the challenge in the authorization request, and sends the verifier during token exchange (RFC 7636).
4. Validate inbound bearer tokens
Before processing any protected request, verify the token signature, issuer, audience, expiration, and required scopes.
✓ Good looks like: Token validation rejects tokens with aud mismatches, expired exp claims, or missing required scopes before any business logic runs.
Policy-Based Authorization
5. Send every protected call to your Policy Decision Point
Don't rely solely on scopes. Evaluate each tool invocation or API call against policy that considers user identity, actor context, request parameters, and business rules.
✓ Good looks like: Your MCP server sends a decision request containing the tool name, inbound token, and relevant parameters (e.g., totalPrice, currency) to the Policy Decision Point before executing the tool.
6. Enforce mixed access models
Allow public tools (like catalog search) without authentication. Require authentication for member-only tools. Require explicit approval for high-value transactions.
✓ Good looks like: Policy permits search_hotels without a token, permits search_hotels_member_rates only with valid authentication and scope, and conditionally permits finalize_booking based on transaction amount, requiring CIBA approval above a threshold (e.g., 200 EUR) or denying outright above a higher threshold (e.g., 1000 EUR).
7. Implement conditional obligations
When policy requires human-in-the-loop approval, return an obligation that triggers CIBA rather than an immediate PERMIT or DENY.
✓ Good looks like: The Policy Decision Point returns {"decision": "PERMIT", "obligations": [{"type": "approval_required"}]} for mid-tier transactions. Your MCP server interprets this obligation and initiates CIBA before proceeding.
Token Exchange
8. Exchange tokens at trust boundaries
When your agent-facing token needs to call a backend API, exchange it for a new token with the correct audience and scope. Don't forward the original token.
✓ Good looks like: Your MCP server calls the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, subject_token set to the inbound bearer token, and audience set to the backend API identifier. The exchanged token has aud matching the backend API, not the MCP layer.
9. Preserve actor chains
Use the act claim to record which clients acted on behalf of the user at each delegation step.
✓ Good looks like: The exchanged token includes nested act claims: {"sub": "user-123", "act": {"sub": "mcp-client", "act": {"sub": "chatgpt-client"}}}. Backend logs can trace the full delegation path.
Client-Initiated Back-Channel Communication Authentication
10. Initiate CIBA when policy requires approval
When your Policy Decision Point returns an approval obligation, start a CIBA flow by calling the Back-Channel Communication authentication endpoint with the user's login_hint and transaction context.
✓ Good looks like: Your MCP server posts to /bc-authorize with login_hint, binding_message (e.g., "Approve booking for 450 EUR"), and scope. It receives an auth_req_id and stores it mapped to the server-side transaction ID.
11. Poll for CIBA completion
After initiating CIBA, poll the token endpoint using the auth_req_id until the user approves or denies the request.
✓ Good looks like: Your server polls /token with grant_type=urn:openid:params:grant-type:ciba and the auth_req_id. It handles authorization_pending, access_denied, and successful token responses. The widget polls your server's transaction status endpoint, not the authorization server directly.
12. Bind approval to the transaction
Don't approve a generic action. Bind the CIBA request to specific transaction details (amount, currency, booking ID) so the user knows exactly what they're authorizing.
✓ Good looks like: The binding_message shown during CIBA approval includes the transaction amount and currency. The backend validates that the approved auth_req_id matches the transaction ID before confirming the booking.
Common Mistakes
- Forwarding agent tokens to backend APIs. This overloads token semantics and prevents audience-based validation. Use token exchange instead.
- Skipping Policy Decision Point calls. Scope checks alone can't enforce transaction-level rules like amount thresholds or conditional approval. Send every protected call to your policy engine.
- Letting the widget call CIBA directly. The widget doesn't have the user context or policy obligation. The MCP server or backend should initiate CIBA and manage the approval lifecycle.
- Using the same scope namespace for multiple resources. This breaks token exchange and audience isolation. Define distinct scopes for each protected surface.
- Omitting
code_verifierin PKCE. Without the verifier, you're vulnerable to authorization code interception. Always generate, hash, and verify the Proof Key for Code Exchange.
Next Steps
After you've verified each checkpoint:
- Test unauthenticated → authenticated transitions. Confirm that crossing into protected functionality triggers the OAuth flow and that the agent retries with a valid token.
- Test transaction approval flows. Verify that mid-tier transactions require CIBA approval and that high-value transactions are denied outright.
- Audit token exchange logs. Confirm that exchanged tokens carry the correct audience, scope, and nested actor claims.
- Review policy decision logs. Validate that every protected call went through your Policy Decision Point and that obligations were enforced correctly.
If your AI agent needs to act across trust levels, OAuth 2.0 gives you the protocol. This checklist gives you the checkpoints.
