Namespace Nexus\Mcp\Client\Auth

A bearer access token an authorization server issued for one MCP server.

The authorization response an MCP client receives, read from the redirect URI the user-agent landed on.

How this client identifies itself to the authorization servers protecting the MCP servers it talks to.

An authorization request awaiting the user-agent: the URL to open, plus the per-request state the client records before redirecting so it can validate the response.

HTTP client decorator that presents an OAuth 2.1 bearer token to a protected MCP server, obtains one when challenged, and steps its scopes up when the server says they are insufficient. Hand it to StreamableHttpClientTransport in place of the default client.

An OAuth client identifier bound to the authorization server that honours it.

Registration store that keeps registrations for the lifetime of the process only, so a restart registers again rather than reusing an identifier it can no longer prove it owns.

Token store that keeps tokens for the lifetime of the process only.

Holds the client identifiers obtained through Dynamic Client Registration, keyed by the authorization server that issued them so credentials are never carried across a server change.

Holds the access tokens a client has obtained, keyed by the MCP server each token is bound to. The issuer that minted a token travels on the token itself. Implementations are responsible for storing tokens confidentially.

The one leg of the OAuth flow the SDK cannot perform: putting the authorization URL in front of a resource owner and collecting the redirect the user-agent lands on. The SDK owns PKCE, the state value, the expected issuer, the URL it builds, and every validation of the response. An implementation only has to open $redirect->url and return where the user-agent ended up.

What a client does when an MCP server answers that the scopes its token carries are insufficient.