OAuth vs API keys for OfflineCreator MCP

Fresh evidence supports controls, not a universal winner

The product facts on this page were checked on August 9, 2026 against OfflineCreator's current setup page, npm release 0.1.2, and both live OAuth metadata documents. The protocol comparison uses the July 28, 2026 MCP authorization revision plus IETF OAuth security guidance. Refresh these sources monthly because endpoint metadata, package setup, client behavior, and scope handling can change independently.

Recent practitioner coverage was degraded and not specific enough to prove that OAuth or API keys are universally safer. An open DevSpace pull request describes a cached OAuth client ID becoming invalid after its local registration row disappeared; its proposed recovery is specific to that implementation and does not establish OfflineCreator behavior. A July 2026 RubyGems advisory describes a cache path that exposed legacy full-access keys, while scoped keys were outside that incident. It illustrates the blast radius of broad, long-lived keys, not a measured comparison of OfflineCreator credentials.

No fresh client-by-client acceptance run, independent audit, breach-rate study, setup-time benchmark, or reliability benchmark was found for OfflineCreator's two paths. The verdict therefore rests on documented lifecycle and least-privilege controls. It does not claim that browser OAuth always prevents leakage, that scoped keys cannot leak, or that one path is faster or more reliable.

Review evidence by the claim it can support

Use the OfflineCreator setup page and published package README for the preference order, client configuration, key-storage guidance, revocation instruction, and cloud-processing boundary. Use the live authorization-server and protected-resource metadata for advertised endpoints, grants, PKCE method, bearer method, and scope names. Use the pinned @offlinecreator/mcp@0.1.2 server source for the TOOL_SCOPES omit-on-register behavior. Metadata and package ledgers do not prove that every MCP client completes consent, refresh, or revocation correctly.

Use the MCP authorization revision and IETF security guidance for normative token handling. The recent DevSpace, PostHog, and RubyGems records are narrow implementation examples. They are retained as qualified evidence of registration-state, audit-attribution, and credential-caching failure modes, not as product claims or population-level evidence.

Compare the actual credential and recovery paths

OAuth adds discovery, client registration, browser authorization, an authorization-code exchange, PKCE, access-token use, and potentially refresh. OfflineCreator's live metadata advertises authorization-code and refresh-token grants, dynamic registration, S256 PKCE, a token endpoint, and a revocation endpoint. Its protected-resource metadata names the MCP resource, advertises models, read, and generate scopes, and permits bearer credentials in the header.

The API-key fallback is shorter but more manual: create a personal key in Settings, copy the secret once, inject it through the client environment or fixed Authorization header, and replace or revoke it when exposure is suspected. Separately, the published @offlinecreator/mcp@0.1.2 server maps each MCP tool to a models, read, or generate requirement and omits registering tools whose required scope is absent when a non-empty scopes list is supplied. A shorter setup is not evidence of lower risk; it means the operator, rather than the OAuth client and authorization server, owns more of the credential lifecycle.

OAuth lifecycle

Consent, code exchange, access token, optional refresh, revokeMore protocol state, with a user-facing authorization decision and advertised server metadata.

API-key lifecycle

Issue, copy once, store, rotate, revokeLess protocol machinery, with direct operational responsibility for the long-lived secret.

Shared control

models, read, and generate permissionsLive metadata advertises those scope names; package 0.1.2 maps tools to the same categories before registration.

Do not confuse browser consent with automatic credential safety

The current MCP authorization specification requires PKCE in the browser authorization sequence, a resource parameter for the intended MCP server, authorization on every protected HTTP request, and audience validation by the server. It forbids access tokens in URI query strings. It also says clients must protect refresh tokens in storage and transit and must not assume a refresh token will be issued.

Those controls reduce specific OAuth attack paths; they do not make a bearer token harmless after theft. RFC 6750 explains that any holder of a bearer token can use its associated authority and recommends TLS, scoped and audience-restricted tokens, short lifetimes, and headers rather than page URLs. The same possession risk applies operationally to a personal API key, so both paths need secret-safe logs, configurations, backups, and incident procedures.

OAuth and API keys can also fail in shared layers. A July 2026 PostHog change fixed activity-log attribution for writes authenticated by either a personal API key or an OAuth token. That is implementation-specific practitioner evidence, not an OfflineCreator defect, but it is a useful review prompt: verify actor attribution for both credential types instead of assuming the authentication label guarantees an adequate audit trail.

Continue to the transport or deployment decision

If the unresolved choice is hosted HTTP versus a client-launched subprocess, continue to the remote MCP versus stdio comparison. If the credential decision is complete, return to the comparison directory for client, API, billing, and deployment alternatives. Use the cloud-versus-LocalForge comparison only when the actual requirement is cloud processing versus on-device generation; changing OAuth to an API key does not move Studio generation on-device.

Editorial boundary

This page owns only the OAuth-versus-personal-API-key decision for OfflineCreator MCP. It does not own remote-versus-stdio transport mechanics, general OAuth implementation guidance, client-specific setup syntax, or cloud-versus-on-device processing. Keep the recommendation conditional on current client support, preserve the documented key fallback, and refresh live metadata and package documentation before changing the verdict.