The MCP authorization specification assumes a person at the keyboard. The client discovers your protected resource metadata, sends the user to an authorization server, the user consents, and the client gets an access token scoped to your server. That flow is correct and you should implement it. It is also the flow enterprise administrators are starting to push back on.
The objection is not about OAuth. It is about who decides. When an AI client in the enterprise connects to your MCP server, per-user consent means every employee individually grants an agent access to company data in your product. The security team sees a consent screen they do not control, a grant they cannot inventory, and a refresh token living somewhere in a client they did not deploy. What they want instead is the pattern they already use for SSO: the identity provider knows the employee, the administrator approves the application once, and access follows the employee record.
This is what "cross-app access" means in current discussion, and it is worth understanding now because the buyer will raise it before the specification settles.
The shape of the flow
The work in progress at the IETF is an identity assertion authorization grant. It composes pieces that already exist rather than inventing a new protocol. In outline:
- The enterprise administrator establishes, in the identity provider, that a given client application may access a given resource application, with a defined set of scopes. This is configuration in the IdP, not a runtime consent screen.
- The client authenticates the user to the IdP as it normally does and holds an identity assertion for that user.
- The client presents that assertion to the IdP's token endpoint as an RFC 8693 token exchange and receives a short-lived, audience-restricted cross-app grant naming the user, the client, and the target resource.
- The client presents that grant to the resource application's authorization server, using the JWT bearer assertion grant of RFC 7523, and receives an access token for the resource.
Your MCP server sits at step four. It still validates a normal OAuth 2.1 access token, still checks the audience, still enforces per-user scoping. What changed is the provenance of that token: it was issued because an administrator authorized the application and the IdP vouched for the user, not because the user clicked Allow.
Why an enterprise buyer prefers it
Four reasons come up repeatedly in reviews.
- Inventory. Administrators can list which agent clients may reach which vendors, in one place, rather than reconstructing it from per-user grants across many products.
- Lifecycle. Access is tied to the IdP's record of the employee. When the account is disabled or removed from a group, the assertion stops being issued, and the assertions are short-lived by design. Long-lived refresh tokens held by third-party clients are the thing security teams dislike most about the consent model.
- No consent fatigue. Users are poor judges of what an agent is asking for. Moving the decision to an administrator is the same argument that moved SaaS logins to SSO.
- Credential surface. Nothing long-lived for your product ends up stored in the client. The grant is minted per exchange and expires in minutes.
None of this removes your obligations. The IdP decides that a client may ask. Your server still decides what that user may do.
What to build today
The draft is a draft. Identity vendors are shipping early support, and the details will move. Do not rebuild your authorization stack around it. Do make the choices that keep the door open:
Separate authentication from authorization decisions. Your tool handlers should read subject, tenant, and entitlements from a validated token context, never from the flow that produced it. If handlers branch on how the user logged in, adding a grant type later touches every tool.
Support more than one grant at your token endpoint. If your product's authorization server is your own, plan for an additional assertion-based grant alongside the authorization code flow. If you use a hosted identity product, ask the vendor where the identity assertion grant sits on their roadmap and record the answer.
Keep the client identity distinct from the user identity. The audit event for a tool call should carry both: which user, and which client application acted for them. That distinction is what makes an administrator-brokered model auditable, and it is useful under plain per-user consent too.
Model admin-scoped entitlements. IdP-brokered access implies the administrator constrains what the client may request. If your scopes are coarse - one read and one write - you cannot express that constraint. Scope design is a prerequisite, not a follow-on.
Keep the interactive flow. Individual users, small teams, and clients outside the enterprise will keep using it. This is an additional path for enterprise tenants, not a replacement.
What to say in a security review
If a reviewer asks whether you support cross-app access, an accurate answer today is usually: not yet, here is what we do instead, and here is what our server already has in place for it. Then show the three things that matter regardless of grant type - audience-restricted tokens that only your server accepts, server-enforced per-user and per-tenant scoping, and audit events naming user, client, and tool. Claiming support for a draft you have not implemented is the kind of statement that turns a questionnaire into an engineering call.
If the reviewer's real concern is offboarding, answer that directly. How long after an account is disabled does the agent stop working? A short number, with the token and cache lifetimes that produce it, settles more of the conversation than any roadmap commitment.
When this does not apply to you
If your customers are individuals or small teams without a managed identity provider, none of this is urgent. Implement the MCP authorization spec well, keep tokens short, and revisit when an enterprise prospect asks.
If your MCP server is internal - your own employees, your own IdP - you can get most of the benefit today with token exchange inside your own trust boundary, and you do not need a cross-organization grant at all.
We track the authorization drafts and directory requirements as part of ongoing support, and enterprise identity design is the core of a governed platform engagement. If an enterprise customer has asked you about admin-brokered access and you are not sure what to answer, tell us what you have built.