Skip to content

SEP-2352: Clarify authorization server binding and migration #2352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mcp-commander merged 13 commits into from
Mar 28, 2026
+34 −1
Merged

SEP-2352: Clarify authorization server binding and migration #2352

Changes from all commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
dcbfb63
docs: clarify authorization server binding and multi-AS behavior
dend Mar 4, 2026
a4e271a
Update docs/specification/draft/basic/authorization.mdx
localden Mar 5, 2026
6e1657b
Update docs/specification/draft/basic/authorization.mdx
localden Mar 5, 2026
8a5112c
Merge branch 'main' into den/as
dend Mar 5, 2026
25aed5a
Trigger CI
dend Mar 5, 2026
d133654
Update docs/specification/draft/basic/authorization.mdx
localden Mar 6, 2026
a0c163f
Update docs/specification/draft/basic/authorization.mdx
dend Mar 6, 2026
c6813f3
Update docs/specification/draft/basic/authorization.mdx
dend Mar 6, 2026
aa60a6c
Update docs/specification/draft/basic/authorization.mdx
dend Mar 6, 2026
46be379
Update docs/specification/draft/basic/authorization.mdx
localden Mar 16, 2026
4ff1403
Reorder AS binding paragraphs: non-portable cases before CIMD
localden Mar 23, 2026
af043cb
Merge branch 'main' into den/as
localden Mar 23, 2026
865c40f
Ground multi-AS credential isolation in RFC 6749 Section 2.2
localden Mar 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 34 additions & 1 deletion docs/specification/draft/basic/authorization.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,9 +85,20 @@ The specific use of `authorization_servers` is beyond the scope of this specific
OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)) for
guidance on implementation details.

Implementors should note that Protected Resource Metadata documents can define multiple authorization servers. The responsibility for selecting which authorization server to use lies with the MCP client, following the guidelines specified in
Implementors should note that Protected Resource Metadata documents
can define multiple authorization servers. The responsibility for
selecting which authorization server to use lies with the MCP client,
following the guidelines specified in
[RFC9728 Section 7.6 "Authorization Servers"](https://datatracker.ietf.org/doc/html/rfc9728#name-authorization-servers).

When multiple authorization servers are listed in `authorization_servers`, each is an
independent OAuth 2.0 authorization server. Consistent with
[RFC 6749 Section 2.2](https://datatracker.ietf.org/doc/html/rfc6749#section-2.2), client
identifiers are unique to the authorization server that issued them. Clients **MUST** maintain
separate registration state (client credentials, tokens) per authorization server and
**MUST NOT** assume that credentials valid for one authorization server will be accepted by
another.

### Protected Resource Metadata Discovery Requirements

MCP servers **MUST** implement one of the following discovery mechanisms to provide authorization server location information to MCP clients:
Expand Down Expand Up @@ -208,6 +219,28 @@ Clients supporting all options **SHOULD** follow the following priority order:
3. Use Dynamic Client Registration as a fallback if the Authorization Server supports it (via `registration_endpoint` in OAuth Authorization Server Metadata)
4. Prompt the user to enter the client information if no other option is available

### Authorization Server Binding

Clients that use pre-registered credentials, or persist client credentials obtained via Dynamic Client
Registration, **MUST** associate those
credentials with the specific authorization server that issued them,
keyed by the authorization server's `issuer` identifier. When the
authorization server changes (detected via updated protected
resource metadata), clients **MUST NOT** reuse client credentials
from a different authorization server and **MUST** re-register
with the new authorization server.

Pre-registered credentials are inherently specific to a particular
authorization server. If the authorization server indicated by
protected resource metadata no longer matches the one the
credentials were registered with, clients **SHOULD** surface an
error rather than silently attempting to use mismatched credentials.
Comment thread
localden marked this conversation as resolved.

Client IDs based on Client ID Metadata Documents are portable
across authorization servers, since they are self-hosted HTTPS URLs
resolved by the authorization server on demand. No re-registration
is needed when the authorization server changes.

### Client ID Metadata Documents

MCP clients and authorization servers **SHOULD** support OAuth Client ID Metadata Documents as specified in
Expand Down
Loading