How OfflineCreator remote MCP OAuth works

Use a decision path for connection and revocation

For a remote client that supports MCP OAuth, start with the documented server URL and browser flow instead of copying a personal API key into the client file. Before granting access, compare the requested scopes with the task: model discovery should not silently become authority to generate. After authorization, verify that the client stores tokens securely, sends bearer tokens only in the Authorization header, and binds requests to the advertised MCP resource.

If the client is lost, the connection is no longer needed, or the granted authority looks broader than expected, use the documented management control to revoke that OAuth connection. In the pinned worker, the revocation POST verifies the management session, validates CSRF, confirms that the signed-in user owns the grant, awaits OAUTH_PROVIDER.revokeGrant for that grant and user, and returns a success redirect only after the awaited call completes. That synchronous ordering is what immediate grant revocation means here.

Treat that handler completion as an implementation boundary, not a measured propagation guarantee. This research did not revoke a live grant, retry an old access or refresh token, measure caches or distributed propagation, establish a timing SLA, or test a request already in flight. A reviewer should still make a fresh MCP request after revocation and confirm rejection before calling an incident contained.

A useful acceptance record pairs each advertised capability with one observation: metadata discovery, the scopes shown at consent, the scopes represented after approval, the tools visible under that grant, and a rejected protected request after revocation. Do not substitute a successful browser redirect for those security checks.

Trace authorization code and PKCE from discovery to token

The first boundary is discovery. OfflineCreator's protected-resource document names https://mcp.offlinecreatorstudio.com/mcp as the resource, points to a same-origin authorization server, lists models, read, and generate as supported scopes, and says bearer credentials belong in the Authorization header. The authorization-server document then supplies the authorize, token, registration, and revocation endpoints. It advertises the code response type, S256 as its PKCE method, and support for an issuer parameter in authorization responses.

Under the July 28, 2026 MCP authorization specification, a compatible client generates a PKCE verifier and S256 challenge, records the expected issuer, and sends the target resource in both authorization and token requests. After browser authorization, the client validates a returned issuer when required, then sends the authorization code, original verifier, and resource to the token endpoint. The verifier links the token exchange to the client that created the challenge; the resource value identifies the MCP server for which the token is requested.

Discover

Read protected-resource and authorization-server metadataValidate the advertised issuer and endpoints before beginning the browser flow.

Authorize

Open the browser with resource, scopes, and an S256 challengeKeep the PKCE verifier in the client; do not send it in the authorization request.

Exchange

Redeem the code with the verifier and the same resourceThen send the access token in the Authorization header, never in a URI query string.

Review scopes, refresh, and token boundaries separately

OfflineCreator's resource metadata advertises models, read, and generate. The pinned authorization-worker helper defines exactly those supported values, defaults an empty request to models and read, removes duplicates, and drops unsupported permissions; its focused tests cover the default, deduplication, and unsupported-value removal. The MCP specification separately tells clients to request only scopes needed for the intended operation and to prefer a scope challenge from the server when one is present.

The same pinned worker computes the filtered scope list for the consent page and renders every retained scope with a description. On approval, it computes the filtered list again, supplies it to completeAuthorization, stores it in authorization properties, and then redirects to the client. This is the evidence for scoped consent on this page. It does not say that a user can select or deselect individual checkboxes: the shown implementation offers Allow access or Cancel for the filtered request as a whole.

The published @offlinecreator/mcp 0.1.2 server package supplies a narrower implementation fact: it maps list_models to models, read-oriented account and generation tools to read, and generation, upload, and cancellation tools to generate. When the package receives a nonempty scope list, it omits tools whose mapped scope is absent. When scopes are missing or empty, it exposes every mapped tool. This package behavior supports scope-to-tool filtering, but it does not establish what the hosted browser consent screen displayed or which scopes any user approved.

Refresh is a separate capability. OfflineCreator's authorization metadata advertises the refresh_token grant, but the MCP specification says clients must not assume a refresh token will be issued and must keep any refresh token confidential in transit and storage. Therefore an advertised grant cannot be converted into claims about token lifetime, rotation, client storage, or automatic renewal. A reviewer should inspect the chosen client's storage behavior and an actual token response before approving a persistent connection.

Access-token validation also belongs on the server side. Current MCP security requirements say clients include the resource parameter, servers accept only tokens intended for their resource, and an MCP server must not pass the inbound MCP token through to an upstream API. OfflineCreator's metadata advertises the expected resource and header bearer method, but metadata alone cannot prove runtime audience checks or absence of token passthrough.

Evidence boundary and unresolved verification

The immutable promise is supported at a precise implementation level. Scoped consent is the worker's supported-scope filtering, per-scope display, and storage of the filtered list during approval. Immediate grant revocation is the management handler awaiting revokeGrant before it sends the success redirect. Separate public metadata establishes authorization-code, refresh-token, S256 PKCE, registration, token, and revocation capabilities, while the MCP specification supplies the protocol security baseline.

No recent community statement is used to support this page's product claims. The August 9, 2026 last30days pass returned forty-six items with zero OfflineCreator-relevant OAuth records, while Reddit ended partial after HTTP 429, Instagram errored, and X was unconfigured. Those access gaps are not treated as community silence; the claim ledger relies on current primary documentation and metadata instead.

This pass reviewed pinned authorization-worker source but did not connect a production client, observe the deployed consent page, capture tokens, measure token lifetime, exercise refresh rotation, test audience rejection, or revoke a live grant. It did not independently measure deployed behavior, token-rejection propagation, already in-flight requests, or any timing SLA, and it was not a penetration test or independent audit.

The implementation links point to stable line anchors at commit 6bb242b2 in OfflineCreator's private GitHub repository. Anonymous requests currently return 404 rather than source text. Repository reviewers with authentication can open the permalinks, and the cited lines were verified directly against the checkout at that commit.