MCP enterprise-managed authorisation: letting your identity provider decide

In most MCP set-ups today, each developer connects each MCP client to each MCP server, one browser consent at a time. That works for one person and a few tools. In a company it means nobody centrally decides which AI tools may reach which internal systems, and offboarding means revoking grants service by service. MCP's Enterprise-Managed Authorization extension puts the company's identity provider (IdP) in the middle of that decision. On 23 October 2026 the MCP authorisation extensions repository published it, and the OAuth Client Credentials extension, as stable, dated revisions. This article explains what the flow does, what changed last week, and where its limits are.

What changed on 23 October

Enterprise-Managed Authorization was promoted to stable in June. On 23 October the ext-auth repository reorganised both of its extensions into the layout for stable extensions: each now has a revision keyed to the 2026-07-28 core protocol revision, with a separate draft copy where future changes collect. The commits say the specification text is unchanged apart from the line naming the protocol revision. The OAuth Client Credentials extension moved from the draft folder to stable at the same time.

The layout follows SEP-3392, a proposal for an extension lifecycle of experimental, beta and stable stages. Under that proposal, a stable extension changes only with a new core protocol revision. One caution: SEP-3392 was still an open pull request when we checked on 27 October, and it describes its classification of the existing extensions as a proposal for the core maintainers. The repository has adopted the convention ahead of the proposal's acceptance.

How enterprise-managed authorisation works

The specification applies an IETF draft, the Identity Assertion JWT Authorization Grant, to MCP. There are four parties: the MCP client, the MCP server, the authorisation server that issues tokens for that MCP server, and the enterprise IdP.

1. Single sign-on. The user signs in to the MCP client through the IdP, with OpenID Connect or SAML. The client receives an identity assertion, such as an ID token.
2. Token exchange at the IdP. The client asks the IdP to exchange that assertion for an ID-JAG, an identity assertion JWT authorisation grant, naming the MCP server's authorisation server as the audience. The IdP evaluates administrator-defined policy and decides whether this client may act for this user at this MCP server, with these scopes.
3. Access token request. The client presents the ID-JAG to the MCP server's authorisation server, which validates it and issues an access token. The specification requires that token to be audience-restricted to the MCP server named in the grant.
4. Calls. The client uses the access token with the MCP server as usual.

The user never sees a per-server consent screen. The specification lists three benefits: users no longer connect each client to each server by hand, administrators gain visibility and control over which MCP servers are used, and clients can get new tokens without user interaction.

Clients discover support through the authorisation server's metadata, which lists the ID-JAG grant profile. The MCP documentation adds that extensions are opt-in and never active by default, and points to a support matrix for which clients implement it.

What the identity provider sees, and what it doesn't

The specification is careful about scope. The IdP takes part in issuing the access token, but its visibility "does not extend to the actual MCP traffic between the MCP Client and Server." It can enforce which users may use which clients with which servers and, if the server defines fine-grained OAuth scopes, which scopes they may request. The specification's own example is engineers getting read-only access from a code editor to a source control MCP server, while another group gets read and write access to an internal documentation app.

Three consequences follow:

• Policy is only as fine as the scopes. If an MCP server offers one scope that covers every tool, the IdP's decision is all or nothing. Ask MCP server vendors which scopes they define.
• Revocation has a delay. The overview page says revoking access at the IdP takes effect across MCP servers. The IdP stops issuing new grants at once, but an access token already issued remains usable until it expires, unless the server's authorisation server revokes it too. The specification's example access token lasts 86,400 seconds, a full day. Check the lifetimes your servers issue.
• Tool-level control and audit still sit elsewhere. The IdP decides whether a token is issued. What the agent then does with each tool call is outside its view, so per-tool permissions, approvals and logs of calls still need a place in your design.

The client credentials extension

The OAuth Client Credentials extension covers the other common case: machine-to-machine access with no user, such as a CI job or a scheduled agent. Credentials are registered out of band, dynamic client registration is not used, and clients authenticate with a signed JWT (recommended) or a client secret. If your automation currently uses a person's token to reach an MCP server, this is the documented way to give it its own identity.

What it means for engineering and security leaders

• Ask your vendors. For each MCP client and server you use, ask whether it supports the enterprise-managed authorisation extension, and how its scopes map to tools.
• Start with the IdP policy you would want anyway: which groups may use which AI clients with which servers, read or write.
• Shorten token lifetimes where revocation speed matters, and confirm what happens to issued tokens when someone leaves.
• Give automation its own credentials through client credentials rather than borrowed user tokens.
• Keep the call-level layer. Identity decides who may connect. It does not decide whether a particular tool call should run.
• Note the moving parts. The grant is based on an IETF draft, and the lifecycle proposal it is filed under is not yet accepted.

In SpanDock, the MCP gateway (Premium and Enterprise plans) is the call-level layer: it applies per-person and per-group permissions to each tool, can use each person's own account at a connector so the service's permissions apply too, and records every call. Company single sign-on with OIDC is on the Enterprise plan; see identity and audit.