AntworkAntwork
Start free
How it worksWho it's forFeaturesPricingDocsSign in
LANGUAGE
Developer Docs

Authentication

OAuth 2.1 with PKCE. No API keys exist, and there is no way to get one.

01

OAuth scopes

4 scopes

The Antwork MCP server implements OAuth 2.1 with PKCE and dynamic client registration (RFC 7591), so MCP clients can connect without you pre-registering each one. Tokens are scoped, revocable, and issued per-client.

Each tool requires one of four scopes. The consent screen lists the scopes a client is requesting so you can approve or deny them granularly.

ScopeAccessWhat it grants
readReadRead posts, social accounts, workspace settings, analytics. No mutations.
writeWriteCreate / edit / delete drafts and scheduled posts. Mutate media library and workspace settings. Does not publish.
publishDestructivePublish posts to connected social platforms and schedule them for future publishing. Granted only when the user explicitly approves.
mediaWriteUpload and attach images / video / PDFs to posts. Separate from write so granular consent is possible.

Token lifecycle

  • Access tokens are short-lived JWTs (5 minute TTL).
  • Refresh tokens are long-lived and stored server-side. Standard refresh_token grant.
  • Revoke via the standard /oauth/revoke endpoint (RFC 7009) or from Settings → Connected AIs in your Antwork dashboard. Revocation invalidates the refresh token immediately.
  • Each MCP client (Claude desktop, Claude Code, Cursor, …) gets its own token. Revoking one client does not affect others.
02

The endpoints

6

Everything below is served by the authorization server at https://api.antwork.io. A client that reads the two discovery documents needs nothing else from this page.

ScopeWhat it grants
/.well-known/oauth-protected-resourceRFC 9728. Names the resource and the authorization server.
/.well-known/oauth-authorization-serverRFC 8414. Every endpoint below, plus the supported scopes, grants and PKCE methods.
POST /oauth/registerRFC 7591 dynamic client registration. Takes a client name and redirect URIs, returns a client id. No secret: clients are public.
GET /oauth/authorizeSends the user to the Antwork consent screen. code_challenge is required and must be S256.
POST /oauth/tokenExchanges the code plus verifier, or a refresh token. Accepts form-urlencoded and JSON.
POST /oauth/revokeRFC 7009. Invalidates a refresh token; returns 200 whatever you send it.

Discovery endpoints

  • GET /.well-known/oauth-protected-resource — RFC 9728 resource metadata.
  • GET /.well-known/oauth-authorization-server — RFC 8414 authorization server metadata.
  • POST /oauth/register — RFC 7591 dynamic client registration.
  • POST /oauth/token — authorization-code and refresh-token grants. PKCE S256 required.
  • POST /oauth/revoke — RFC 7009 token revocation.
03

Connecting a client of your own

Registration is open, so an MCP client nobody has heard of can connect: POST /oauth/register with a name and a redirect URI, send the user through /oauth/authorize, and exchange the code. The consent screen names your client to the user, and the grant is theirs to revoke. This is how every client on the quick-start list connects — there is no private arrangement for any of them.

There is no unattended access

The authorization server offers authorization_code and refresh_token and nothing else. No client_credentials, no device code, no API keys, and no UI that could issue one. Every token is bound to a user who approved it in a browser, which is also why the CLI cannot run in CI.