OAuth MCP image generation without API keys in client config

Use the remote OAuth endpoint for supported clients

OfflineCreator's recommended remote connection is https://mcp.offlinecreatorstudio.com/mcp. The live protected-resource metadata identifies that resource, names its authorization server, supports bearer tokens in headers, and advertises models, read, and generate scopes. The product page and package direct users to add the URL to a compatible MCP client, select Connect, and complete Studio sign-in and consent in the browser.

This flow keeps a personal API key out of the client configuration. It does not make generation anonymous or local: authorization is tied to the Studio account, and generation inputs go to the disclosed cloud provider selected for the model. Revoke an unwanted connection from account settings rather than deleting only the local JSON.

The current product guide presents connection selectors for Cursor, Claude Code, Claude Desktop, Hermes, Windsurf, and VS Code, but that list is setup documentation rather than a dated compatibility test matrix. Treat the intended client and build as an acceptance-test target. The page documents Cursor's remote URL, browser sign-in, reload, and revocation path; it does not establish that every listed client build handles discovery, consent return, token refresh, scope changes, and revocation identically.

Keep API-key fallbacks in secret configuration

The package retains local stdio and a legacy remote API-key fallback for clients or environments that cannot complete remote OAuth. A fallback key belongs in an environment variable or supported secret field, never in a URL, prompt, source file, or chat transcript. The documentation explicitly rejects query-string keys and limits package API calls to a trusted HTTPS origin except localhost.

Treat fallback setup as a different credential model, not as an OAuth troubleshooting shortcut. Create the narrowest available scope, record where the key is installed, rotate it if it may have leaked, and remove stale copies after migration. Tool visibility follows models, read, and generate authorization scopes.

Separate authorization success from generation readiness

A completed browser consent flow proves that the client obtained authorization; it does not prove that every intended tool is visible or that a paid generation should begin. First confirm the server entry points to the protected resource named in the live metadata. Then inspect the granted models, read, and generate scopes, verify model discovery, and check the account balance. Only proceed to generation when the visible tool set matches the operator's intended authority.

The current MCP authorization tutorial describes the architecture behind that browser handoff: an unauthenticated MCP request receives a 401 challenge pointing to protected-resource metadata, the client discovers authorization information, registers through a supported route, and follows the OAuth 2.1 authorization-code flow with PKCE. That protocol sequence explains what a compatible client must implement; it is not evidence that a particular client build completed OfflineCreator's flow.

Use a low-risk acceptance sequence: connect, list models, read credits, inspect the generation tool schema, and revoke the connection. Reconnect only if the client and account behavior match the documented path. Record the client name and build because the server's OAuth metadata cannot establish how every client presents consent, caches tools, or reloads a changed configuration. This draft therefore does not claim universal client compatibility.

If OAuth discovery fails, gather the client error and MCP logs before switching credential models. A stdio or legacy remote API-key fallback creates a long-lived secret-handling obligation and should be chosen deliberately, not pasted in as a quick retry. The package documents those fallback paths and trusted-origin rules, while the recommended path keeps a personal key out of the client file.

Score client readiness with evidence rather than a compatibility label. Confirm that the client follows the 401 challenge, opens the browser on the advertised issuer, returns from consent, sends bearer credentials in headers, refreshes its visible tool list, and stops working after revocation. A client that connects but keeps a stale all-tools cache does not pass the scope portion of this decision.

Verify connection, scope, and revocation

After browser consent, reload the client's MCP servers, confirm model discovery, and check that visible tools match the granted scope before attempting a generation. Test revocation with a non-production connection and confirm the client can no longer use protected tools. Record the client build because OAuth and reload behavior can change independently of the server.

Make fallback selection explicit. If remote OAuth cannot be validated for the intended client build, decide whether local stdio's process and environment-secret requirements fit the deployment or whether the legacy bearer-header route is acceptable. Record the key owner, scope, storage location, rotation path, and removal condition before using either fallback.