Revoke an OfflineCreator MCP key or OAuth connection

Choose the revocation control that matches the credential

OfflineCreator publishes three distinct containment choices. For a fallback personal API key, its Privacy Policy says Settings can revoke one key or all API keys. For remote OAuth, the product page says Settings can revoke an OAuth connection. These controls should not be treated as interchangeable: the first two concern personal API keys, while the third concerns a browser-authorized connection that does not place a personal API key in the client file.

Use one-key revocation when one named fallback key is lost, exposed, retired, or no longer assigned to its automation. Use revoke-all when you cannot identify the affected key or when every personal key should stop being trusted. Use OAuth-connection revocation for a connected remote client. OfflineCreator's public Terms add a clear urgency rule for keys: if a key may be compromised, revoke it immediately in Settings.

One personal key

Revoke the selected key in SettingsUse when the affected fallback credential can be identified.

All personal keys

Revoke all API keys in SettingsUse when the affected key is uncertain or every personal key must be replaced.

One OAuth connection

Revoke the connection in SettingsUse for a browser-authorized remote MCP client rather than a fallback API key.

Follow a decision path before pressing revoke

First identify the connection type. A local stdio or legacy remote fallback configured with a personal API key belongs on the API-key path. The recommended remote connection at https://mcp.offlinecreatorstudio.com/mcp uses OAuth; OfflineCreator says the client file stores no API key for that flow. Do not revoke an unrelated personal key and assume an OAuth connection was removed, or revoke one OAuth connection and assume fallback keys disappeared.

Next decide the containment radius. If a leaked configuration exposes a recognizable key, choose the documented individual-key control. If the copied material is incomplete, several machines held different keys, or the key identity cannot be trusted, choose the documented revoke-all control and plan to issue only the replacements still needed. If the affected client was authorized through browser sign-in, select that OAuth connection in Settings instead of searching a client file for a personal key that the documented flow does not store there.

Finally, preserve evidence without preserving the secret. Record the connection type, non-secret key prefix or client name if the authenticated interface shows one, the time of revocation, and the verification result. Do not put a full key or OAuth token in the incident note. OfflineCreator states that API-key plaintext is not retained after creation and that key secrets are not written to application logs, but this research did not inspect what the authenticated Settings interface displays for either credential type.

Separate the OAuth connection control from the advertised token route

OfflineCreator's live authorization-server metadata advertises https://mcp.offlinecreatorstudio.com/oauth/token as both its token endpoint and its revocation endpoint. The same document advertises authorization-code and refresh-token grants. That is current evidence of the route and advertised protocol capabilities; it is not evidence that a user should paste a token into a browser, call the route manually, or bypass the MCP client's revocation behavior.

RFC 7009 defines token revocation as an HTTPS POST containing a required token and an optional token-type hint. It says the server returns HTTP 200 for a successfully revoked token and also for an invalid token, so a 200 response alone cannot demonstrate that a particular credential was active and then invalidated. The standard also makes related-token invalidation policy-dependent and acknowledges possible propagation delay even though implementations should minimize it.

Use the documented Settings connection control for the account-level action. Treat the metadata route as a discovery fact for compatible OAuth clients and security reviewers. Because this pass did not submit a token, inspect a client request, or observe the hosted server's response, it does not claim that OfflineCreator's endpoint implements every RFC 7009 behavior or that revoking one connection immediately invalidates every cached access token and refresh token.

Verify containment with the old credential, not the settings screen

For an individual key, keep the revoked key only long enough to send one harmless authenticated request to the intended Studio service, then expect that old credential not to authorize the request. Confirm separately that another deliberately retained key still works if your goal was one-key rather than revoke-all containment. For revoke-all, test each known old key and create a replacement only after the old set has been checked. These are proposed acceptance tests, not results from this research pass.

For OAuth, reconnect the same client without starting a new browser authorization and attempt a harmless MCP operation against the advertised resource at https://mcp.offlinecreatorstudio.com/mcp. A successful operation may reflect a still-valid cached access token, a refresh path, incomplete revocation, or a mistaken connection selection; this research did not distinguish those cases. RFC 7009 warns that related-token invalidation depends on server policy and that propagation delay can exist, so record the time and retry boundary rather than translating a Settings confirmation into an unmeasured claim of immediate containment.

A protocol response is not enough by itself. RFC 7009 deliberately uses HTTP 200 for both a revoked token and an invalid token. Verification therefore belongs at the protected MCP resource: the old credential should no longer produce authorized behavior. Stop before any credit-spending generation, use a read-only or otherwise harmless check available to the client, and avoid copying the rejected secret into logs or screenshots.

Continue with the boundary exposed by the incident

After revocation, review personal-key storage if the incident involved local stdio or the legacy remote fallback. Review the broader MCP security boundary if the credential type is uncertain. Use the incident-response page when containment also requires an investigation, evidence preservation, or coordinated replacement rather than a single Settings action.

Evidence boundary and unresolved revocation behavior

The supported comparison is deliberately narrow. OfflineCreator's Privacy Policy documents individual and all-key revocation in Settings; its Terms require immediate key revocation when compromise is possible; its MCP product page documents OAuth-connection revocation in Settings; the live Settings route requires sign-in; and live authorization metadata advertises an HTTPS revocation endpoint. RFC 7009 supplies the general token-revocation semantics used to design a verification check.

No community claim is included because the available recent coverage was insufficient. That limitation is not evidence that discussion or security concerns were absent, and it cannot support a customer-outcome, adoption, or independent-security claim.

This pass did not sign in, create or revoke a personal key, invoke revoke-all, authorize or revoke an OAuth connection, submit to the advertised endpoint, inspect access or refresh tokens, measure propagation, or test a protected request after revocation. The Privacy Policy, MCP product page, and unauthenticated Settings entry response inspected for route evidence do not identify authenticated Settings subroutes or key-revocation API routes. Keep the page draft and require runtime acceptance evidence before describing revocation as immediate, cascading, or independently verified.