Require `token_endpoint_auth_methods_supported` in Client ID Metadata Documents

• Status: Draft
• Type: Standards Track
• Created: 2026-07-27
• Author(s): @max-stytch @stevenlee-oai
• PR: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/3149

Imported from upstream. Proposed as modelcontextprotocol#3149 by @max-stytch on 2026-07-28, where it was still open on 2026-09-25. Accepted into omcp on its technical merit. The text is the author's; only the status, the sponsor field, and documentation links were changed on import.

Reviewed 2026-09-25 — not yet accepted. Held as a draft because no prototype a reviewer can run is cited. Acceptance needs a prototype a reviewer can run, with its setup and the data to run it; Final also needs conformance tests and the reference documentation chapter.

Abstract

This SEP makes the token_endpoint_auth_methods_supported metadata parameter a required property of MCP Client ID Metadata Documents (CIMD), and creates a deprecation path for the singular token_endpoint_auth_method parameter, mirroring the guidance in OpenID Connect RP Metadata Choices 1.0. This enables a CIMD document to be published once and consumed by many authorization servers with differing capabilities. It also deprecates the implicit public-client default that applies when a document declares no authentication method at all. Both deprecations point at the same end state: every CIMD document declares its authentication methods explicitly in token_endpoint_auth_methods_supported. This SEP is agnostic about which authentication methods a given client advertises. It specifies the shape and handling of the field, not its contents.

Motivation

MCP's Client ID Metadata Document mechanism, introduced in SEP-991, carried over the singular token_endpoint_auth_method from RFC 7591 client metadata. It appears in the specification today only in an example document, never in normative prose.

A CIMD document is published at a single URL and consumed by every authorization server the client ever connects to, and those servers do not have uniform capabilities. A single-valued token_endpoint_auth_method gives a client no way to express "any of these, depending on what you support."

The broader OAuth/OIDC ecosystem has already solved this capability negotiation problem by moving from single-valued to multi-valued parameters. RP Metadata Choices 1.0 supplements token_endpoint_auth_method with token_endpoint_auth_methods_supported, and RFC 8414 uses that same name for the mirror-image capability on the authorization server. Adopting it in CIMD documents brings MCP in line with both.

Specification

CIMD Document Requirements

MCP clients publishing a Client ID Metadata Document MUST include the token_endpoint_auth_methods_supported metadata parameter. Its value is a JSON array of strings drawn from the OAuth Token Endpoint Authentication Methods registry established by RFC 7591 Section 4.2.

This extends the metadata document's required-property list in Client Registration, which currently reads:

The metadata document MUST include at least the following properties: client_id, client_name, redirect_uris

The array MUST contain one or more authentication methods the client supports, in no particular order of preference. The restrictions on token endpoint authentication methods in the Client ID Metadata Document specification continue to apply: the array MUST NOT include client_secret_post, client_secret_basic, client_secret_jwt, or any other method based around a shared symmetric secret.

Authorization servers MUST support reading token_endpoint_auth_methods_supported from a CIMD document. Documents that omit it are handled as described in Deprecated Declarations.

For illustration, a client that supports two registered methods might publish:

"token_endpoint_auth_methods_supported": ["none", "private_key_jwt"]

Method Resolution

The client and authorization server determine the set of mutually supported token endpoint client authentication methods by intersecting the client's token_endpoint_auth_methods_supported array with the authorization server's token_endpoint_auth_methods_supported metadata value.

• The client MUST select and use a method from the intersection.
• When the client's singular token_endpoint_auth_method is present and mutually supported, the client SHOULD use that method to preserve compatibility with authorization servers that treat the singular field as binding.
• When the singular method is absent or unsupported, the client MAY select another method from the intersection.
• After reading token_endpoint_auth_methods_supported from the CIMD document, an authorization server SHOULD accept any method in the intersection, unless its local security policy disallows that method for the client.
• If the intersection is empty, the client MUST NOT proceed, and the authorization server MUST reject the client.
• Authorization servers MUST reject any method outside the intersection.

For example:

Deprecated Declarations

Two existing declarations are deprecated but remain supported during the transition to token_endpoint_auth_methods_supported:

1. The singular token_endpoint_auth_method parameter, retained for backwards compatibility with authorization servers that do not support the array.
2. Declaring no authentication method at all, retained for backwards compatibility with documents published before the array was required.

• Clients MUST publish token_endpoint_auth_methods_supported.

• Clients SHOULD additionally publish token_endpoint_auth_method, set to their preferred single value from that array, for as long as the field remains deprecated rather than removed. This follows OpenID Connect RP Metadata Choices 1.0, Section 2:

  To facilitate interoperability with implementations not supporting this specification, deployments SHOULD include the single-valued metadata parameter alongside the corresponding multi-valued metadata parameter with their preferred single value.

• When both parameters are present, token_endpoint_auth_method MUST be a member of token_endpoint_auth_methods_supported. The array is authoritative; the singular value is the client's backwards-compatible preference when it is mutually supported.

• Authorization servers MUST NOT reject a client solely because the singular preferred method is unsupported when another method in the array is mutually supported.

• Authorization servers MAY fall back to token_endpoint_auth_method when the multi-valued parameter is absent — for example, when reading a document published before this requirement took effect.

• Authorization servers MUST treat a document carrying neither parameter as declaring ["none"] until the deprecation period elapses, and MUST reject such a document thereafter.

The following examples show how the singular field behaves during the deprecation period:

Lifecycle

Per the feature lifecycle policy, this SEP proposes the following deprecation entries:

Rationale

token_endpoint_auth_methods_supported was chosen over inventing an MCP-specific field name because it is already the standard name for this capability within OAuth/OpenID ecosystems.

This SEP intentionally does not recommend a specific set of authentication methods. Which methods a client can support is determined by its deployment model, and a blanket recommendation would be wrong for some large class of clients.

The client selects a mutually supported method without requiring the authorization server to communicate a selected method back to the client. Preserving the singular preference when possible keeps existing authorization-server behavior intact.

The field is required (MUST) rather than recommended (SHOULD) because explicit behavior is crucial for authentication mechanisms. A required field gives servers a single place to look and makes conformance checkable. The cost — that existing documents must add one property — is trivial.

Alternatives considered

Making token_endpoint_auth_methods_supported optional (SHOULD)

• Rejected. A SHOULD leaves authorization servers unable to depend on the field, so they must keep consulting the singular field indefinitely and the lowest-common-denominator problem persists for any client that skips it. Requiring the field while deprecating (not removing) the old one achieves the transition without an interoperability break.

Publishing multiple metadata documents, one per token_endpoint_auth_method

• Rejected because it defeats the purpose of CIMD. The metadata URL is the client_id, so publishing one document per authentication method splits a single logical client into several distinct client identities. User consent records, revocation, audit logs, and rate limits would fragment across those identities, and the same application would appear to users as different clients depending on which authorization server they connected through.
• The maintenance burden compounds the problem: every additional method multiplies the documents that must be hosted and kept in sync. Other independently varying properties, such as callback identifiers, multiply that cardinality further. New URLs also complicate authorization-server allowlists and existing registrations, while query-string variants can be rejected because Client ID Metadata Document identifiers SHOULD NOT include query strings. Multiple documents can serve as a migration fallback, but one document keeps the client's identity stable as its capabilities evolve.

Backward Compatibility

Existing CIMD documents remain accepted by conformant authorization servers during the deprecation period.

What changes. CIMD documents that omit token_endpoint_auth_methods_supported become non-conformant with that revision. Every client publishing a CIMD document must add the property, even if it only ever supported one authentication method.

What does not change, for now. Every document that is valid today continues to register successfully:

• Documents omitting the array but declaring token_endpoint_auth_method work via the fallback above.
• Documents declaring neither parameter are treated as ["none"], which is the behavior authorization servers already implement in practice and the posture those clients already had.
• Authorization servers that have not yet implemented the multi-valued parameter keep working, because clients SHOULD continue publishing the singular field.

Clients do not need a separate signal indicating whether an authorization server understands the array. When the singular preferred method is supported, using it preserves compatibility with legacy authorization servers. When it is unsupported, a client can try another mutually supported method from the array: an updated authorization server can accept it, while a legacy server may still reject the client. That legacy server would already have rejected the unsupported singular method, so this fallback improves compatibility without creating a new failure case.

What changes at removal. Both accommodations are deprecated, so this is a deferred break rather than an avoided one. When the deprecation period elapses, a document that declares no authentication method is rejected instead of read as ["none"], and clients that never added the array stop registering. The window exists so that the fix — publishing one additional property — can be made on the client's own schedule rather than under an upgrade deadline.

Ordering. Because the requirement lands on clients while the fallback remains available to servers, deployments can migrate independently: a client can add the array before any given server reads it, and a server can start reading it before every client publishes it. Neither side needs to coordinate with the other.

Security Implications

This proposal does not introduce or rank authentication mechanisms. It allows a client to advertise multiple existing methods while preserving the authorization server's ability to enforce its local security policy.

Reference Implementation

ChatGPT's public Client ID Metadata Document advertises two methods and publishes one as its backwards-compatible singular preference:

{
  "token_endpoint_auth_methods_supported": ["none", "private_key_jwt"],
  "token_endpoint_auth_method": "private_key_jwt"
}

Codex advertises and prefers only its supported public-client method:

{
  "token_endpoint_auth_methods_supported": ["none"],
  "token_endpoint_auth_method": "none"
}

Both examples maintain a stable client identifier while exposing a singular preference for authorization servers that do not support the array.

A publicly runnable client/server implementation and conformance tests remain to be linked.

Open Questions

• Should implicit ["none"] and token_endpoint_auth_method be deprecated, or should allowances be made to not break existing CIMD clients?

Acknowledgments

TBD.