You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Align scope selection with the spec chain and stop mutating caller metadata
Drop the authorization-server scopes_supported tier from scope selection.
That list is the server's catalog rather than what the resource needs,
so falling back to it could request every scope the server supports
when the protected resource metadata published an empty list. The
chain is now WWW-Authenticate scope, then PRM scopes_supported, then the
caller-configured scope, then omit; an empty published list falls
through instead of pinning an empty scope. AS metadata is still consulted
for whether offline_access may be added.
The provider now works on a copy of the caller's OAuthClientMetadata, so
the flow's scope selection no longer rewrites the caller's model and the
configured-scope snapshot cannot pick up another provider's discovered
scopes when metadata is reused across providers.
Copy file name to clipboardExpand all lines: docs/client/oauth-clients.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -112,7 +112,7 @@ A nightly job, a CI step, another service. There is no browser and nobody to cli
112
112
What changed:
113
113
114
114
* No `OAuthClientMetadata`, no handlers. You pass `client_id` and `client_secret`; the provider builds a minimal `client_credentials` registration around them and skips dynamic registration entirely.
115
-
*`scope` is a space-separated string, the OAuth wire format. It is the fallback: a scope the server names in its `WWW-Authenticate` challenge or publishes in`scopes_supported` takes precedence.
115
+
*`scope` is a space-separated string, the OAuth wire format. It is the fallback: a scope the server names in its `WWW-Authenticate` challenge or its protected-resource`scopes_supported` takes precedence.
116
116
* Everything downstream is identical: the same `TokenStorage`, the same `httpx2.AsyncClient(auth=...)`, the same `streamable_http_client`.
117
117
118
118
By default the secret travels as HTTP Basic auth on the token request (`client_secret_basic`). Pass `token_endpoint_auth_method="client_secret_post"` to put it in the form body instead. Some authorization servers only accept one of the two.
### Scope selection follows the spec's chain, with the configured scope as the fallback
1995
+
1996
+
The client selects the scope to request from the `WWW-Authenticate` challenge, then the protected resource's `scopes_supported`, then the scope the caller configured on the provider (`ClientCredentialsOAuthProvider(scope=...)`, `PrivateKeyJWTOAuthProvider(scope=...)`, or `OAuthClientMetadata(scope=...)`), and otherwise omits it. Two v1 behaviours changed:
1997
+
1998
+
* The configured scope is now requested when the server advertises no scopes. v1 silently dropped it and sent the token request scope-less. If a strict authorization server now answers `invalid_scope` for a configured scope it does not allowlist, drop or correct the `scope=` argument.
1999
+
* The authorization server's `scopes_supported` no longer supplies the requested scope. v1 fell back to that list, which is the server's whole catalog rather than what the resource needs, so a resource publishing an empty `scopes_supported` could trigger a request for every scope the authorization server supports. If you relied on it, configure the scope on the provider explicitly. The list is still consulted to decide whether `offline_access` may be added ([SEP-2207](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2207)).
2000
+
1994
2001
### Client rejects authorization server metadata with a mismatched `issuer`
1995
2002
1996
2003
During OAuth discovery, `OAuthClientProvider` now validates that the authorization server
0 commit comments