The Model Context Protocol working group ratified spec revision 2025-06-18 on June 18, 2025, and it is the first revision to put MCP on something defenders recognise as a real identity stack. Where the November 2024 spec treated authorization as a recommendation with the OAuth bits sitting awkwardly inside the server, the June revision separates concerns: the MCP server is now an OAuth 2.1 Resource Server, the Authorization Server is a distinct entity advertised via RFC 9728 Protected Resource Metadata, and clients are obliged to send RFC 8707 resource indicators on every token request. The spec also introduced elicitation — mid-session structured input requests from server to user — and removed JSON-RPC batching. For teams shipping enterprise MCP servers, this revision is the inflection point at which you can stop treating MCP as an experiment and start treating it as identity-bearing infrastructure.
Why did the working group reclassify MCP servers as resource servers?
The November 2024 spec let an MCP server double as its own authorization endpoint, which created the same trust collapse that plagued early OAuth deployments before RFC 6749. Tokens issued by the server were verifiable only by the server, which made revocation, audit, and cross-organization use impossible. The June 2025 revision says explicitly that a protected MCP server "MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728)" and advertise its associated authorization server through a WWW-Authenticate challenge or a /.well-known/oauth-protected-resource document. That decoupling matters because it forces operators to plug MCP servers into the same identity provider that issues tokens for the rest of the enterprise — Entra ID, Okta, Auth0, Keycloak — rather than rolling a bespoke credential store per server. Audit trails, conditional access, and step-up authentication become reusable instead of bespoke.
What does the RFC 8707 resource indicator requirement prevent?
Resource indicators (the resource parameter in the token request) explicitly bind an access token to the MCP server it was minted for. Without that binding, a malicious or compromised MCP server in the user's client could replay a token it observed and call a different, more privileged server using the same credential. This is the textbook confused-deputy variant that Auth0, Descope, and the spec authors all called out in their post-release write-ups. With RFC 8707 in force, the authorization server stamps the audience claim with the resource URI, and a downstream server that sees a token addressed to a different audience must reject it. The spec's "Security Considerations" section now requires both clients and servers to validate the audience.
What is elicitation and why is it a new attack surface?
Elicitation lets a server send elicitation/create to the client mid-execution, supplying a JSON schema for the input it wants from the human. The intent is benign — collect a missing date, a confirmation, an API key the user has not yet provided — but the surface is exactly the spot where a poisoned tool description tries to social-engineer the user. Defenders should treat any elicitation request the same way a browser treats a window.prompt() from an iframe: render it in a way that makes the server identity unambiguous, and never auto-fill from local secret stores. The spec explicitly forbids servers from requesting passwords or other sensitive credentials through elicitation, but clients still have to enforce that, and the early SDK implementations (Anthropic's Python and TypeScript SDKs, plus the Microsoft .NET SDK update released alongside the spec) leave the rendering to the host application.
How should an enterprise MCP server configuration actually look?
The minimum viable configuration for a protected MCP server under 2025-06-18 looks like the snippet below. The discovery document points clients at the IdP, the token validation block enforces audience and scope, and the resource URI matches what clients will pass in resource=.
# mcp-server.yaml — 2025-06-18 compliant
protocol_version: "2025-06-18"
resource:
identifier: "https://mcp.example.com/jira"
protected_resource_metadata: "/.well-known/oauth-protected-resource"
authorization:
issuer: "https://login.example.com"
jwks_uri: "https://login.example.com/.well-known/jwks.json"
required_audience: "https://mcp.example.com/jira"
required_scopes_per_tool:
list_issues: ["jira:read"]
create_issue: ["jira:write"]
delete_issue: ["jira:admin"]
pkce_required: true
resource_indicators_required: true # RFC 8707
elicitation:
allow_credential_fields: false # spec MUST
rate_limit_per_session: 3
transport:
http:
streamable: true # batching removed in this rev
Which legacy MCP deployments need a forced migration?
Three groups of deployments break under the new spec and should be on a deprecation timer. First, servers that issued their own bearer tokens without an upstream IdP — they need to be rebuilt to delegate authentication, or they need a thin reverse proxy that adds the protected-resource metadata. Second, clients that hard-coded resource= to the authorization server URL instead of the resource URL — those will receive tokens with the wrong audience and fail validation once servers enforce checks. Third, anything that depended on JSON-RPC batching, which is gone in 2025-06-18; observability tooling that grouped requests by batch ID must move to the session ID instead. The Anthropic, Cloudflare, Microsoft, and Stytch SDKs all shipped compliant releases in July 2025, so the upgrade path exists; the work is the inventory, not the code.
What does a sane rollout plan look like for Q3 and Q4 2025?
Start with discovery. Inventory every MCP server reachable from any agent in the organization, including developer-laptop installations of community servers from the official registry. For each one, record whether it advertises Protected Resource Metadata, whether it requires PKCE, whether it accepts the resource parameter, and which scopes its tools require. Then enroll each server's authorization server into the corporate IdP — either by federating to it or by replacing it with the corporate IdP. Add an MCP-aware reverse proxy at the egress boundary so that token audience and scope can be enforced even when a misbehaving client forgets to send resource=. Finally, write a policy gate that blocks deployment of any MCP server that does not advertise 2025-06-18 or later and does not require resource indicators. The November 2025 spec revision added further authorization clarifications, so the gate's allowed-version list should be a moving target rather than a single pin.
How Safeguard Helps
Safeguard inventories every MCP server connected to your agents, parses each server's protected-resource metadata, and flags servers that still advertise 2025-03-26 or earlier as risk-elevated. Griffin AI cross-references discovered MCP servers against the official registry's namespace records so that a server claiming to be io.github.acme/jira actually traces back to the Acme GitHub organisation rather than a typosquat. Policy gates can require RFC 8707 resource indicators, PKCE, and a corporate IdP issuer before a server is allowed into production, and elicitation flows are logged to the SIEM with the JSON schema attached so analysts can review what servers asked users for. Where a server is non-compliant, Safeguard auto-files a remediation task with the owning team and links it to the spec section the configuration violates, turning a fuzzy "we should upgrade MCP" backlog item into a concrete, audited workflow.