MCP 2026-07-28 authorization: issuer checks and client registration changes

What it is

Status as of 25 October 2026. The 2026-07-28 authorization changes concern issuer validation, registration and credential ownership. Re-check the versioned authorization specification, registration rules and authorization-server metadata before rollout. Client ID Metadata Documents (CIMD) are not newly introduced here: the 2025-11-25 changelog already recommends them. The new revision formally deprecates Dynamic Client Registration (DCR), retaining it for compatibility.

The MCP server is the protected resource, the MCP client obtains access, and the authorization server issues tokens. Changes may therefore belong in different services even when one operator runs all of them. MCP's OAuth framework applies to HTTP deployments; it is not the prescribed credential mechanism for stdio.

Why it matters

An authorization flow must remain associated with the issuer selected when it began. Otherwise, endpoint changes or ambiguous registration records can cause credentials to be used with the wrong authorization server. CIMD also introduces document retrieval and redirect validation responsibilities; recognizing a URL-form client identifier does not establish trust in the application.

How to apply

• Validate authorization responses before code redemption. Clients record the issuer from validated server metadata alongside the authorization attempt's PKCE verifier. Authorization servers should return iss and must advertise support when doing so. Clients compare any returned iss exactly with the recorded value after form decoding, without URL normalization. A mismatch is rejected, including on error responses. If metadata advertises issuer-parameter support but iss is absent, reject; if neither advertises nor supplies it, the specification permits proceeding.
• Bind registration credentials to the issuer. Persist pre-registered or DCR credentials under the issuing server's identifier. Never reuse them at a different issuer. Obtain registration for the new server; for mismatched pre-registration, surface an error. This rule does not make a self-hosted CIMD identifier issuer-specific: the registration specification explicitly allows that URL identifier to be portable without re-registration.
• Follow registration selection rules. Prefer available pre-registration, then CIMD when advertised through client_id_metadata_document_supported, then supported DCR as a compatibility fallback. A CIMD document uses HTTPS with a path and includes client_id, client_name and redirect_uris. Its client_id must equal its document URL; validate the JSON and the requested redirect against the document.
• Harden metadata retrieval. Apply the documented defenses against server-side request forgery when fetching client documents. Consider domain trust policies. CIMD alone cannot prevent impersonation involving localhost redirects; display the redirect hostname during authorization as required.
• Keep legacy DCR correct. Clients must specify an appropriate application_type. Native desktop, CLI and localhost applications should use native; remote browser applications should use web. Investigate registration failures instead of relaxing redirect checks to make them disappear.
• Retain the existing security floor. Verify PKCE support in metadata, protect stored tokens, and validate that incoming tokens are intended for this MCP resource. Upstream API calls need separately issued upstream tokens. The registration migration does not permit token passthrough or removal of consent checks.

Pitfalls

Do not describe DCR as already removed, or CIMD as universally mandatory: its support is a recommendation. As a proposed acceptance test, exercise correct, mismatched and missing issuer responses, an issuer change, and each retained registration path in staging. Check that rejected responses never reach code redemption. These checks target protocol conformance; they do not constitute a security audit of a particular authorization deployment.