MCP Consent Prompts: Four OBO and Token-Exchange Requirements (2026)

An agent that bounces back to a browser consent screen for every new MCP or API call is already broken. The runtime has no session cookie. The fatigue is not “too many dialogs.” It is the assumption that browser SSO will follow the agent.

📑Table of Contents

1. Repeated consent fails because agents cannot use browser SSO
2. OBO retargets the audience with RFC 8693 token exchange
3. Vendor OBO constraints must be checked first
4. ID-JAG is an IdP-mediated alternative still in draft
5. Authorization-server requirements and a production checklist
6. Frequently Asked Questions
7. Summary

Take the inbound token from the first IdP sign-in and exchange it for a short-lived token aimed at each audience. That is the operational meaning of on-behalf-of (OBO). This article compares RFC 8693 token exchange, vendor OBO constraints, and the still-draft ID-JAG path, then gives a pre-production checklist with concrete values.

Classify the flow, then check the four requirements

Classify the current flow as either impersonation or subject-plus-actor delegation, then verify these four requirements on the authorization server:

1. Accept RFC 8693 token-exchange or RFC 7523 jwt-bearer
2. Validate inbound JWT signature / iss / aud / exp
3. Resolve user permissions from (iss, sub)
4. Issue an access token whose aud is the API or MCP

---

What this comparison covers

---

Repeated consent fails because agents cannot use browser SSO

The defect is not the number of consent screens. It is the expectation that SSO will work for a process that cannot maintain a browser cookie.

The usual path consists of three steps.

1. Authenticate the user at the IdP and receive an inbound token
2. Collect authorization for each tool or MCP server
3. Call the tool with that token

Step 2 is where the flow stops. A browser can carry a session cookie across properties. An agent runtime cannot.

Production constraints

Constraints that matter in production:

• A typical id_token expires_in is about 3599 seconds (roughly one hour)
• A token whose aud does not include the recipient must be rejected (OIDC Core §3.1.3.7)
• sub is an IdP-local unique identifier, not an email. Entra uses oid + tid for cross-app identity

---

Do not forward a user bearer

Do not impersonate the user by forwarding a session or a broad bearer token to MCP. Codebasing (2026-08-10) rejects that reuse because logs collapse to “the user did it” and the full permission set is exposed. Strivacity makes the same cut: a login token is authentication evidence, not versioned consent for each MCP action.

If you are still choosing how agents should attach to tools at all, the MCP vs CLI comparison covers that axis. This article stays on the authorization hop.

---

OBO retargets the audience with RFC 8693 token exchange

OBO is not “reuse the same user proof at another API.” It is a POST to /token that mints a new access token with a new audience.

1. Use the first-login id_token (or inbound access token) as subject_token
2. POST grant_type=urn:ietf:params:oauth:grant-type:token-exchange plus client authentication to the external token endpoint. No redirect
3. Send the returned access token to the MCP or API as Authorization: Bearer <exchanged_access_token>

POST /oauth/token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<inbound_id_token>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&audience=https://mcp.example.com
&scope=mcp.execute

How to read the exchanged claims

• iss becomes the resource-side authorization server
• aud moves to the MCP or API
• sub still names the user, but the value can change with the issuer. The spec does not require a byte-identical sub
• act.sub names the acting agent or client

---

Lifetime and dual attribution

The RFC 8693 example response uses expires_in: 3600. In operations, drop the exchanged token much shorter (for example 600 seconds). Arcjet’s agentic-identity guide states the split clearly: a user token alone hides which agent acted; a workload identity alone has no user consent. Secure delegation keeps both subject and actor, downscopes per audience, limits chain growth, and rechecks authorization immediately before a consequential action.

---

What IAM teams should require

NHIMG (2026-08-14) treats RFC 8693 as the emerging control plane and tells IAM teams to require actor, subject, and audience-bound scopes at each trust boundary.

---

Vendor OBO constraints must be checked first

“Supports OBO” is not a single protocol. Fix the grant shape and document the hard limits in a table before you write any code.

RFC 8693 and Entra-family grants

Approach	Grant / flag	Principal	Will not work when	Source
RFC 8693 exchange	urn:ietf:params:oauth:grant-type:token-exchange	subject + optional actor	The authorization server does not implement the grant	IETF RFC 8693
Entra OBO	jwt-bearer + requested_token_use=on_behalf_of	user principal only	App-only tokens, wildcard-reply id_token, custom signing-key middle tier	Microsoft Learn
Agent 365 OBO	Entra OBO as an execution mode	user = subject, agent = actor	Blueprint permissions still need separate admin consent	Microsoft Learn 2026-08-14

---

AgentCore and gateway grants

Approach	Grant / flag	Principal	Will not work when	Source
AgentCore OBO	ON_BEHALF_OF_TOKEN_EXCHANGE	caller + agent	IdP must be set to TOKEN_EXCHANGE or JWT_AUTHORIZATION_GRANT	AWS Docs
Traefik MCP Gateway	RFC 8693 issues Token B	same sub / permissions, new aud	Gateway only forwards or strips headers; the MCP server does the exchange	Traefik Hub docs

---

Sources

Sources (as of August 2026):

• RFC 8693
• Microsoft identity platform OBO
• Agent 365 identity
• AgentCore OBO
• Traefik Hub MCP Gateway

---

Extra Entra limits

Entra adds several easy-to-miss limits.

• Do not relay a middle-tier token to another audience
• Roles stay on the user; the app must not inherit them
• A SPA should pass an access token to a confidential middle tier
• App-only tokens use client credentials, not OBO

---

Execution mode and admin consent

Microsoft Agent 365 (updated 2026-08-14) defines OBO as an execution mode: the signed-in human is the subject and the agent identity is the actor.

That pattern is distinct from both S2S (no user context) and Agentic-User (the agent’s own user account). Blueprint-declared permissions still require admin consent.

---

Exchange flags and actor options

Amazon Bedrock AgentCore uses GetResourceOauth2Token with oauth2Flow=ON_BEHALF_OF_TOKEN_EXCHANGE.

• Grant modes are TOKEN_EXCHANGE (RFC 8693) or JWT_AUTHORIZATION_GRANT (RFC 7523)
• Actor options are NONE, M2M (client credentials plus optional actorTokenScopes), and AWS_IAM_ID_TOKEN_JWT (requires outbound web identity federation)
• The authorization server, not the agent, makes the final grant and scope decision

---

403 check against user RBAC

There is a concrete verification path. Headwaters (2026-08-09) exchanges an inbound bearer via Entra OBO to call Azure AI Search.

Removing the user’s data-plane role returns HTTP 403, which shows authorization stayed bound to the user rather than a shared app key.

---

Gateway only forwards headers

Do not expect the gateway to do the exchange. Traefik Hub documents that the gateway only forwards or strips the Authorization header. Token B is minted by the MCP server and the IdP.

---

ID-JAG is an IdP-mediated alternative still in draft

If the enterprise question is “may this agent reach that external service,” and you want the IdP to answer it, look at ID-JAG. It is not a drop-in standard on every IdP today.

Two hops:

1. Use RFC 8693 at the IdP to mint an ID-JAG assertion (aud = the external authorization server)
2. Present that assertion to the external AS with RFC 7523 jwt-bearer and receive an access token

Draft constraints

Constraints:

• draft-ietf-oauth-identity-assertion-authz-grant-04 (updated 2026-05-21, expires 2026-11-22, WG Document)
• The IdP must issue ID-JAG, the external AS must accept jwt-bearer, and some processing rules can still change
• The draft example access token uses expires_in: 86400 and scopes such as agent.read agent.write

---

Enterprise-managed authorization

The enterprise wording is Enterprise-Managed Authorization. NHIMG describes moving per-connector consent screens into IdP policy. Prefer short-lived, sender-constrained grants (DPoP / cnf) and task-scoped RAR. Keep interactive on-behalf-of use distinct from autonomous agent-as-subject use.

A neighboring implementation of “do not give agents ambient MCP defaults” is the Cloudflare OS Gatekeeper model.

---

Authorization-server requirements and a production checklist

Existing SSO is not enough. OBO adds grant acceptance and MCP-audience token issuance. Without those, repeated consent does not go away. Judge the token endpoint, not the UX copy.

Four requirements. The fifth is optional.

1. Accept RFC 8693 token-exchange, or RFC 7523 ID-JAG / jwt-bearer
2. Validate the inbound JWT (signature / iss / aud / exp). OIDC SSO can often reuse JWKS checks. SAML SSO usually needs new JWT validation
3. Resolve the in-service user and permissions from (iss, sub)
4. Issue an access token whose aud is the API or MCP
5. (Optional) Downscope the requested scopes

Production checklist

Reader checklist:

• ✓ Reject impersonation (reuse of the user token); exchange a task-scoped token
• ✓ Keep both subject and actor on the token
• ✓ Split audiences for MCP and backend
• ✓ Perform the exchange in the MCP server or a dedicated broker; keep the gateway as a forwarder
• ✓ Recheck authorization immediately before a consequential action (a valid delegation is not current intent)
• ✓ Keep revocation and a full delegation-chain audit log
• ✓ Do not assume ID-JAG if the IdP cannot issue it

---

Delegation blast radius

A durable, overly broad delegated token also widens tool-injection blast radius. For the MCP attack surface, see the Agentjacking write-up. Authorization design and exploit paths are separate topics; forwarding a wide bearer makes both worse.

---

Frequently Asked Questions

Q1. After the first login, can every MCP be called with no further consent?

No. The receiving authorization server must accept the grant, and the user must already hold the relevant scope. Unconsented permissions are never issued.

---

Q2. Is it faster to pass the user’s access token to MCP?

It looks faster but it is unsafe. The audit trail collapses to the user and the full permission set becomes exposed. Always exchange a short-lived, audience-locked token.

---

Q3. If we already use Entra, can we skip RFC 8693?

Entra OBO is jwt-bearer plus requested_token_use=on_behalf_of. That is not RFC 8693. Use the grant documented by your IdP.

---

Q4. Can ID-JAG be the production default now?

No. It is a WG draft updated 2026-05-21 and marked to expire 2026-11-22. Confirm both the IdP and the external AS before depending on it.

---

Q5. Will the gateway perform the token exchange?

Traefik Hub’s documentation states that the gateway only forwards or strips the Authorization header. The token exchange must be performed by the MCP server and the IdP.

---

Related articles:

• 12331
• 12872
• 13549

Summary

Repeated consent is close to a design bug: asking an agent to behave like browser SSO.

Near-term implementation

The near-term implementation is RFC 8693 or a vendor OBO flow that exchanges a short-lived token while keeping subject and actor. ID-JAG fits IdP-centric policy, but it is still a draft. Do not design as if every IdP already speaks it.

---

Next check on the authorization server

Next step: classify the current flow as impersonation or subject-plus-actor delegation, then check these four authorization-server requirements in place.

1. Accept RFC 8693 token-exchange or RFC 7523 jwt-bearer
2. Validate inbound JWT signature/iss/aud/exp
3. Resolve user permissions from (iss, sub)
4. Issue an access token whose aud is the API or MCP

The useful judgment is audience separation and auditability, not fewer consent screens.