Configure OAuth metadata
Exportoauth next to auth in src/server.ts:
sunpeak start then serves both protected-resource discovery forms:
resource to the exact public MCP resource identifier. Token verification must enforce that resource or audience so the server does not accept tokens minted for another service.
OAuth resource and authorization server URLs must use HTTPS. Plain HTTP is accepted only for loopback development URLs.
Request more scopes
The auth function receives the parsed MCP request as its second argument. Returnauthorized: false with insufficient_scope when a request needs scopes the current token does not have. sunpeak returns a 403 challenge that clients can use for an OAuth scope upgrade.
scopes. The client combines that challenge with scopes requested earlier before it starts the new authorization flow, so the server does not need to repeat scopes required only by other operations.
Use the composable handlers
The same configuration works with Node and Web Standard handlers:/.well-known/oauth-protected-resource paths to it. The Node handler recognizes those paths itself and falls through for unrelated routes.
For a custom router, createOAuthProtectedResourceMetadata, getOAuthProtectedResourceMetadataUrl, and createOAuthChallenge are exported from sunpeak/mcp.
Client behavior in the inspector
The inspector follows the MCP OAuth discovery flow and supports these registration paths in order:- A pre-registered client ID, with an optional secret
- A URL-based client ID backed by an HTTPS Client ID Metadata Document
- Dynamic Client Registration when the authorization server advertises it
code_challenge_methods_supported to include S256. When protected-resource metadata advertises more than one authorization server, the inspector asks which issuer to use and keeps client credentials, tokens, and PKCE state separate for each issuer.
For a pre-registered confidential client, choose automatic client authentication or explicitly select client_secret_basic, client_secret_post, or none. The selected method must be advertised by the authorization server when it publishes token_endpoint_auth_methods_supported.
Runtime insufficient_scope challenges start a fresh authorization flow with the union of previously requested scopes and the scopes required for the current operation. The inspector does not use a refresh-token request as a substitute for user authorization of new scopes.
The inspector advertises the refresh_token grant. It adds offline_access to the authorization request only when the selected authorization server lists that scope in scopes_supported.
Use Clear local authorization to discard the inspector’s cached tokens, client registration, PKCE verifier, and discovery state. This does not revoke tokens at the authorization server.
The Client ID Metadata Document URL must use HTTPS, include a non-root path, and omit embedded credentials and fragments. The document must list the inspector callback URL that appears in the authorization request.
Token verification
Verify all of these claims before returningAuthInfo:
- Signature and signing algorithm
- Issuer
- Audience or resource indicator
- Expiration and not-before time
- Required scopes for the current MCP request
See also
Server Entry
The
src/server.ts entry point and AuthInfo type reference.MCP OAuth Authorization for MCP Apps
The protocol flow, client behavior, version differences, and server checklist.