MCP protocol adds centralised authentication for enterprise use

The Model Context Protocol (MCP) has just tackled the most repeated objection in corporate AI deployments: identity management. As reported by InfoQ on Monday 6 July, the standard driven by Anthropic to connect language models with external tools is adding centralised authentication designed for enterprise environments, so that access to MCP servers can be governed from the company's own identity infrastructure.

To understand the scope, it helps to remember where we are coming from. The MCP specification adopted OAuth 2.1 as the foundation of its authorization layer, and since the June 2025 revision MCP servers behave as standard resource servers, with protected resource metadata so clients can discover who issues the tokens. That tidied up the protocol, but left a very practical problem untouched: each server negotiated its own consent, user by user. In an organisation with dozens of MCP servers and hundreds of employees, the result was repeated authorization screens, tokens scattered across clients and no single place from which to audit or revoke access.

What changes with centralised authentication

Under the centralised model, those decisions move to the corporate identity provider, the same Okta, Microsoft Entra or Google Workspace that already manages the rest of the company's applications. The administrator defines once which users and which clients may talk to each MCP server, and employees stop chaining consent screens: if policy allows it, access is granted; if not, there is nothing to accept. The idea does not come out of nowhere. The protocol community had spent months working on enterprise managed authorization proposals, such as the Cross App Access flow championed by Okta, aimed at exactly this: letting an IdP broker access between MCP clients and servers without relying on individual consent. The finer implementation details are in the InfoQ analysis, recommended reading if you plan to roll this out.

Why it matters

Because identity, more than model quality, was the real bottleneck for corporate MCP adoption. Platform teams repeat the same three questions in every evaluation: who has access to which tool, how that access is revoked when someone leaves the company, and how all of it is evidenced in a SOC 2 or ISO 27001 audit. With tokens spread across teams and individual consents, none of them had a good answer. Centralised authorization turns those questions into routine IdP operations: onboarding and offboarding are handled like any other corporate application and the access log lives in a single place. It also weakens the incentive for shadow IT, because the sanctioned path stops being more painful than the shortcut. For Anthropic this is strategic too: Claude Code and Claude Desktop are today the most widely deployed MCP clients, and every identity friction removed widens the ground where they can be rolled out.

Who this is useful for

The clearest beneficiaries are three profiles:

Platform and IT teams that want to roll out Claude Desktop, Claude Code or other MCP clients to the whole workforce without multiplying consents and support tickets.
Security teams that demand traceability and centralised revocation as a condition for approving any agent deployment.
* Vendors selling MCP servers to large accounts, who until now improvised their own identity layer on top of the protocol.

Anyone using MCP for personal projects will barely notice the change: the existing OAuth flow keeps working as before. And, as with any new identity component, it is worth testing the IdP integration in a controlled environment before extending it to the whole organisation.

At ElephantPink we build custom MCP servers, and the identity conversation was the uncomfortable part of every corporate project. Having the protocol solve it out of the box is not the flashiest news of the year, but it is the kind that decides whether this technology reaches production or stays in the demo.