OAuth discovery is convenient because a client can learn where to register, authorize, and exchange tokens. The dangerous moment comes when previously stored credentials are sent to an endpoint learned from a different trust context.
An endpoint can look like a valid OAuth endpoint while belonging to the wrong party.
Keep four actors distinct
The user or deployment administrator decides which service the client should trust. The MCP client manages the authorization flow. The resource server exposes the tools. The authorization server issues the credentials used to access them.
Those roles can be operated by different organizations. Discovering an authorization server does not, by itself, justify sending it credentials registered with another issuer.
The MCP Python SDK advisory describes missing issuer validation and credential binding across OAuth paths. Depending on the flow, exposed material could include client secrets, authorization codes, PKCE verifiers, or signed client assertions.
Validate the discovered issuer against the expected issuer and keep stored registrations bound to that identity.
Trace one registration
Suppose a client has registered with authorization server A. Its stored record should include the issuer and associated registration context, not merely a client ID and secret.
Later, an MCP connection advertises authorization server B. The client must not silently reuse A's registration with B. It needs to apply the appropriate trust and registration flow for that issuer.
For unattended providers using sensitive, preconfigured credentials, explicitly configure the expected issuer where the SDK supports it. There is no interactive user to notice that the identity provider changed.
Review the less-used paths
An implementation may validate the issuer during normal discovery and miss the same decision in a fallback, cached-metadata path, or error recovery.
Review them together:
- Does returned issuer metadata match the expected issuer according to the protocol's comparison rules?
- Is each stored registration retrieved by its issuer context?
- Can switching the resource server change the destination of existing client secrets or assertions?
- Are endpoints and audiences handled according to the SDK's documented authorization flow?
Use the vendor's fixed SDK version and validation behavior. Handwritten URL prefix checks are a poor substitute for issuer-aware protocol handling.
If a client already connected
An upgrade fixes future behavior. It does not revoke credentials already disclosed.
Determine which authorization flows ran and which secrets could have been transmitted. Clear legacy registrations that lack the necessary binding, revoke exposed tokens, and rotate client secrets or signing keys where exposure is plausible.
Retain endpoint and flow evidence without preserving sensitive token contents in ordinary logs.