Authorization changedspecification/draft/basic/authorization/index
Nearest release: v2.1.309, published under an hour before this site recorded the change. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Recorded here
Lines+11added
Lines−11removed
From line
49
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
The whole hunk
from line 49, old and new numbered
/
from line 49
4949
5050The *authorization server* is responsible for interacting with the user (if necessary) and issuing access tokens for use at the MCP server.
5151The implementation details of the authorization server are beyond the scope of this specification. It may be hosted with the
52resource server or a separate entity. [Authorization Server Discovery](/specification/draft/basic/authorization/authorization-server-discovery)
52resource server or a separate entity. [Authorization Server Discovery](/specification/draft/basic/authorization/authorization-server-discovery.md)
5353specifies how an MCP server indicates the location of its corresponding authorization server to a client.
5454
5555## Overview
from line 57
57571. Authorization servers **MUST** implement OAuth 2.1 with appropriate security
5858 measures for both confidential and public clients.
5959
602. Authorization servers and MCP clients **SHOULD** support [OAuth Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents)
602. Authorization servers and MCP clients **SHOULD** support [OAuth Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents)
6161 ([draft-ietf-oauth-client-id-metadata-document-00](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00)).
6262
63633. Authorization servers and MCP clients **MAY** support the OAuth 2.0 Dynamic Client Registration
6464 Protocol ([RFC7591](https://datatracker.ietf.org/doc/html/rfc7591)). Note that
65 [Dynamic Client Registration](/specification/draft/basic/authorization/client-registration#dynamic-client-registration)
65 [Dynamic Client Registration](/specification/draft/basic/authorization/client-registration.md#dynamic-client-registration)
6666 is deprecated and retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents.
6767
68684. MCP servers **MUST** implement OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)).
69 MCP clients **MUST** use OAuth 2.0 Protected Resource Metadata for [authorization server discovery](/specification/draft/basic/authorization/authorization-server-discovery).
69 MCP clients **MUST** use OAuth 2.0 Protected Resource Metadata for [authorization server discovery](/specification/draft/basic/authorization/authorization-server-discovery.md).
7070
71715. MCP authorization servers **MUST** provide at least one of the following discovery mechanisms:
7272
from line 73
7373 * OAuth 2.0 Authorization Server Metadata ([RFC8414](https://datatracker.ietf.org/doc/html/rfc8414))
7474 * [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)
7575
76 MCP clients **MUST** support both [discovery mechanisms](/specification/draft/basic/authorization/authorization-server-discovery#authorization-server-metadata-discovery) to obtain the information required to interact with the authorization server.
76 MCP clients **MUST** support both [discovery mechanisms](/specification/draft/basic/authorization/authorization-server-discovery.md#authorization-server-metadata-discovery) to obtain the information required to interact with the authorization server.
7777
7878## Authorization Server Discovery
7979
from line 81
8181Resource Metadata, and MCP clients determine authorization server endpoints and supported
8282capabilities through authorization server metadata discovery. Implementations **MUST**
8383follow the normative discovery requirements defined in
84[Authorization Server Discovery](/specification/draft/basic/authorization/authorization-server-discovery).
84[Authorization Server Discovery](/specification/draft/basic/authorization/authorization-server-discovery.md).
8585
8686## Client Registration
8787
from line 88
8888Before initiating the authorization flow, MCP clients **MUST** obtain a client ID through
8989one of three registration mechanisms: Client ID Metadata Documents, pre-registration, or
9090Dynamic Client Registration, following the requirements and selection priority defined in
91[Client Registration](/specification/draft/basic/authorization/client-registration).
91[Client Registration](/specification/draft/basic/authorization/client-registration.md).
9292
9393## Scope Selection Strategy
9494
from line 125
1251252. **If `scope` is not available**, use all scopes defined in `scopes_supported` from the Protected Resource Metadata document, omitting the `scope` parameter if `scopes_supported` is undefined.
126126
127127The `scopes_supported` field is intended to represent the minimal set of scopes necessary
128for basic functionality (see [Scope Minimization](/docs/draft/tutorials/security/security_best_practices#scope-minimization)),
128for basic functionality (see [Scope Minimization](/docs/draft/tutorials/security/security_best_practices.md#scope-minimization)),
129129with additional scopes requested incrementally through the step-up authorization flow steps
130130described in the [Scope Challenge Handling](#scope-challenge-handling) section.
131131
from line 132
132132## Authorization Flow Steps
133133
134134The registration step shown in the flow uses one of the mechanisms defined in
135[Client Registration](/specification/draft/basic/authorization/client-registration).
135[Client Registration](/specification/draft/basic/authorization/client-registration.md).
136136
137137The complete Authorization flow proceeds as follows:
138138
from line 185
185185
186186### Authorization Response Validation
187187
188Before redirecting the user-agent, the client **MUST** record the `issuer` value from the selected authorization server's validated metadata document (see [Authorization Server Metadata Discovery](/specification/draft/basic/authorization/authorization-server-discovery#authorization-server-metadata-discovery)) and associate it with the same per-request record used to store the PKCE code verifier (and the `state` value, if used). The validation in this section depends on that recorded value being authentic; it provides no protection if the expected issuer was obtained from an unvalidated source.
188Before redirecting the user-agent, the client **MUST** record the `issuer` value from the selected authorization server's validated metadata document (see [Authorization Server Metadata Discovery](/specification/draft/basic/authorization/authorization-server-discovery.md#authorization-server-metadata-discovery)) and associate it with the same per-request record used to store the PKCE code verifier (and the `state` value, if used). The validation in this section depends on that recorded value being authentic; it provides no protection if the expected issuer was obtained from an unvalidated source.
189189
190190MCP authorization servers **SHOULD** include the `iss` parameter in authorization responses, including error responses, as defined in [RFC9207 Section 2](https://datatracker.ietf.org/doc/html/rfc9207#section-2). Authorization servers that include the `iss` parameter **MUST** advertise this by setting `authorization_response_iss_parameter_supported` to `true` in their metadata ([RFC9207 Section 2.3](https://datatracker.ietf.org/doc/html/rfc9207#section-2.3)).
191191
from line 403
403403## Security Considerations
404404
405405Implementations of this specification **MUST** follow the normative security
406requirements in [Security Considerations](/specification/draft/basic/authorization/security-considerations),
406requirements in [Security Considerations](/specification/draft/basic/authorization/security-considerations.md),
407407covering token audience binding and validation, token theft, communication security,
408408authorization code protection, mix-up and confused deputy attacks, open redirection,
409409and Client ID Metadata Document security.
No line in this hunk matches that.