OAuth 2.1 and PKCE for remote MCP

Treat scopes, refresh, and revocation as separate controls

Scopes describe authority, not the strength of PKCE. Current MCP guidance tells clients to request only the permissions needed and to treat an operation-specific scope in a WWW-Authenticate challenge as authoritative for that operation. If an existing token lacks authority, the server can return HTTP 403 with insufficient_scope and the required scopes. A client may then run a bounded step-up authorization flow rather than silently broadening the original grant.

Refresh tokens solve a different problem: obtaining new access without repeating browser consent. The MCP specification says a client must keep any refresh token confidential and must not assume that one will be issued. Authorization-server metadata can advertise refresh-token grant support, but that advertisement does not prove issuance, rotation, lifetime, secure client storage, or successful renewal.

Revocation is another independent boundary. OfflineCreator's public connection page directs users to revoke OAuth connections from Settings, and its authorization-server metadata publishes a revocation endpoint. Those public records establish that a user control and endpoint are advertised; they do not establish when an already issued access token, refresh token, cached credential, or request in flight becomes unusable. Verify rejection with a fresh protected request before treating a lost-client incident as contained.

Read OfflineCreator's current OAuth surface as a concrete example

OfflineCreator currently documents https://mcp.offlinecreatorstudio.com/mcp as its recommended remote OAuth connection. Its live protected-resource metadata names that URL as the resource, points to the same-origin authorization server, advertises models, read, and generate scopes, and specifies bearer tokens in the header. The authorization-server metadata advertises the authorization-code and refresh-token grants, S256 PKCE, issuer information in authorization responses, Client ID Metadata Documents, and authorization, token, registration, and revocation endpoints.

These public records expose the service's current discovery surface, not its complete internal enforcement. They show what the deployed service advertises to clients and what connection method the product page recommends. They do not prove which scopes a particular client requests, what the browser consent page displays, how tokens are stored, whether a token response includes refresh credentials, or whether every deployed request passes audience and scope checks.

Use the live metadata as a worked reading exercise: find the protected resource, authorization server, supported challenge method, and endpoint set, then compare each value with the role it plays in the protocol sequence. A security assessment of how OfflineCreator filters consent or executes revocation is a separate product-verification task.

models

Advertised by protected-resource metadataThe public metadata names the scope but does not define a complete tool-to-scope mapping.

read

Advertised by protected-resource metadataA client still needs the server's operation-specific challenge or public tool contract to know exact requirements.

generate

Advertised by protected-resource metadataThe metadata label alone does not establish which individual operations a granted token can perform.

Start with discovery, not a pasted token

OAuth for remote MCP is a chain of roles and metadata, not a token field added to an MCP configuration. The remote MCP server is the protected resource, the MCP client requests access for a user, and an authorization server handles browser interaction and issues tokens. Authorization is optional in MCP overall, but the current specification defines this flow for HTTP transports and says stdio implementations should obtain credentials from their environment instead.

A client commonly learns that authorization is required from an HTTP 401 challenge. It follows the protected-resource metadata URL to identify the authorization server, then reads that server's metadata to discover its authorization, token, and registration capabilities. Before opening a browser, the client must also obtain a client identifier through a Client ID Metadata Document, pre-registration, or the older dynamic-registration fallback. Discovery matters because an MCP URL alone does not safely tell a client where to send an authorization code or which PKCE method the server accepts.

Protected resource

The remote MCP serverIt accepts access tokens and must validate that each token was issued for this resource.

OAuth client

The MCP applicationIt discovers metadata, opens the browser, retains PKCE state, exchanges the code, and sends the resulting bearer token.

Authorization server

The issuer and consent boundaryIt identifies the client, interacts with the user, and issues tokens for the MCP resource.

Follow the authorization code and PKCE verifier

PKCE protects the authorization-code handoff. For each authorization attempt, the client creates a high-entropy code verifier and derives an S256 challenge by hashing that verifier with SHA-256 and base64url-encoding the result. The browser authorization request carries the challenge, not the verifier. When consent succeeds, the authorization server redirects an authorization code to the client's registered callback. The client then sends the code and its original verifier directly to the token endpoint.

The token endpoint transforms the received verifier in the same way and compares it with the challenge bound to the code. A party that intercepts only the authorization code cannot complete that comparison without the verifier. Current MCP security requirements make PKCE mandatory, tell capable clients to use S256, and require clients to verify PKCE support in authorization-server metadata before proceeding. PKCE does not encrypt prompts, authenticate the MCP tool itself, or replace exact redirect-URI checks; it narrowly protects code redemption.

The learner's checkpoint is mechanical: the verifier never travels in the browser authorization request, the challenge never substitutes for the verifier at the token endpoint, and a verifier from one attempt cannot redeem a code bound to another challenge. These invariants explain PKCE without claiming anything about OfflineCreator's private consent renderer or grant-management implementation.

Authorize

Send code_challenge with S256Keep the random verifier in the client and associate it with this single authorization attempt.

Callback

Receive a short-lived authorization codeValidate the response against the recorded issuer and request state before choosing a token endpoint.

Exchange

Send code plus code_verifierThe token endpoint rejects redemption when the verifier does not reproduce the stored challenge.

Bind the token to the MCP resource

PKCE answers who can redeem a captured code; resource indicators answer where the resulting token is intended to work. The current MCP flow requires the client to include the same resource parameter in both authorization and token requests. That value identifies the canonical MCP server URI. The resource server must then validate that an incoming token was issued specifically for it rather than accepting a valid token minted for another service.

After exchange, the client sends the access token in the Authorization header on every protected HTTP request. The specification forbids putting access tokens in the URI query string. It also forbids an MCP server from passing the inbound MCP token through to an upstream API: if the server calls another provider, that relationship needs a separate credential issued for that upstream audience. PKCE, resource binding, and bearer-token handling therefore cover different boundaries and should be reviewed independently.

Resource parameter

Present in authorization and token requestsUse the canonical remote MCP URI, including a meaningful path when that path identifies the individual server.

Bearer delivery

Authorization header onlyDo not put an access token in a connection URL, query parameter, copied example, or log.

Upstream access

A separate token boundaryThe token granted to the MCP server is not a credential for a downstream model or storage provider.

Choose the next guide by the boundary you need

Use the tool-scopes guide when your question is which permissions should expose model, read, or generation operations. Use the stdio guide when the MCP client launches a local process and credentials come from its environment rather than this HTTP authorization flow. Return to the learning center when you need to place OAuth alongside transports, tools, resources, tasks, and the wider media-generation lifecycle.

Those routes own their narrower subjects. This page explains remote authorization discovery, the browser code flow, PKCE, resource binding, refresh, and revocation. It does not claim universal client configuration or replace a security assessment of OfflineCreator's deployed service.

Evidence boundary and recent implementation signal

The protocol explanation comes from the official MCP 2026-07-28 authorization specification and security considerations, with PKCE mechanics checked against RFC 7636. Product statements are limited to OfflineCreator's public connection page and live OAuth metadata. Those sources support the documented endpoint and advertised capabilities; they do not establish a successful client connection, the deployed consent display, token contents, refresh rotation, audience enforcement, generation behavior, or post-revocation rejection. A third-party analysis by Descope, updated for the July 2026 revision, corroborates the base OAuth 2.1 and PKCE framework and identifies six additional formal requirements added by that revision—issuer validation per RFC 9207, OIDC application_type registration, credential binding, offline_access scope, scope step-up union computation, and discovery clarification—plus the promotion of Enterprise-Managed Authorization to an official extension; it is an identity vendor's perspective, not an independent audit.

Recent practitioner evidence is narrow. A Cline pull request merged on August 7 added pre-registered OAuth-client support for remote MCP servers that do not offer dynamic client registration. Its discussion reports tests against a simulated server that enforced S256, but this is a project-specific implementation anecdote, not proof that every client follows the current MCP flow or that OfflineCreator interoperates with Cline.

Editorially, the recent community pass is too limited to support broader adoption, compatibility, reliability, or security conclusions. Apart from the qualified Cline example, this draft relies on current primary protocol and product records and treats missing corroboration as a research gap rather than evidence of absence. Independent penetration testing, a compatibility matrix, token-lifetime measurements, refresh and revocation tests, and customer outcomes remain outside the evidence set.