Autenticación

OAuth 2.1 con PKCE. Los clientes sin navegador pueden enviar una clave de API en su lugar.

Scopes OAuth

4 scopes

El servidor MCP de Antwork implementa OAuth 2.1 con PKCE y registro dinámico de clientes (RFC 7591), de forma que los clientes MCP pueden conectarse sin que tengas que pre-registrarlos uno a uno. Los tokens son scoped, revocables y emitidos por cliente.

Cada tool requiere uno de cuatro scopes. La pantalla de consentimiento lista los scopes que un cliente solicita para que puedas aprobarlos o denegarlos de forma granular.

Scope	Acceso	Qué concede
read	Read	Leer posts, cuentas sociales, ajustes del workspace y analítica. Sin mutaciones.
write	Write	Crear / editar / borrar borradores y posts programados. Mutar la biblioteca de medios y la configuración del workspace. No publica.
publish	Destructive	Publicar posts en las plataformas sociales conectadas y programarlos para publicación futura. Solo se concede cuando el usuario aprueba explícitamente.
media	Write	Subir y adjuntar imágenes / vídeo / PDFs a posts. Separado de `write` para permitir consentimiento granular.

Ciclo de vida del token

Los access tokens son JWTs de corta duración (TTL de 5 minutos).
Los refresh tokens son de larga duración y se guardan en el servidor. Grant refresh_token estándar.
Revoca vía el endpoint estándar /oauth/revoke (RFC 7009) o desde Settings → Connected AIs en tu dashboard de Antwork. La revocación invalida el refresh token al instante.
Cada cliente MCP (Claude desktop, Claude Code, Cursor, …) recibe su propio token. Revocar uno no afecta a los demás.

Los endpoints

Todo lo de abajo lo sirve el servidor de autorización en https://api.antwork.io. Un cliente que lea los dos documentos de descubrimiento no necesita nada más de esta página.

Scope	Qué concede
/.well-known/oauth-protected-resource	RFC 9728. Nombra el recurso y el servidor de autorización.
/.well-known/oauth-authorization-server	RFC 8414. Todos los endpoints de abajo, más los scopes, grants y métodos PKCE admitidos.
POST /oauth/register	Registro dinámico de clientes (RFC 7591). Recibe un nombre y redirect URIs, devuelve un client id. Sin secreto: los clientes son públicos.
GET /oauth/authorize	Lleva al usuario a la pantalla de consentimiento de Antwork. `code_challenge` es obligatorio y debe ser S256.
POST /oauth/token	Intercambia el código más el verifier, o un refresh token. Acepta form-urlencoded y JSON.
POST /oauth/revoke	RFC 7009. Invalida un refresh token; devuelve 200 le mandes lo que le mandes.

Endpoints de discovery

GET /.well-known/oauth-protected-resource — metadatos de recurso RFC 9728.
GET /.well-known/oauth-authorization-server — metadatos del authorization server RFC 8414.
POST /oauth/register — registro dinámico de clientes RFC 7591.
POST /oauth/token — grants authorization-code y refresh-token. PKCE S256 requerido.
POST /oauth/revoke — revocación de tokens RFC 7009.

Conectar un cliente propio

El registro está abierto, así que puede conectarse un cliente MCP del que nadie ha oído hablar: POST /oauth/register con un nombre y una redirect URI, manda al usuario por /oauth/authorize e intercambia el código. La pantalla de consentimiento le nombra tu cliente al usuario, y el permiso es suyo y suyo es revocarlo. Así se conecta cada cliente de la lista de inicio rápido: no hay acuerdo privado con ninguno.

El acceso desatendido usa una clave de API

El servidor de autorización ofrece authorization_code y refresh_token, y nada más: ni client_credentials ni device code, así que cada token OAuth está ligado a un usuario que lo aprobó en un navegador. Un cliente sin navegador (un trabajo de CI, el Agent SDK, codex exec) envía una clave de API de Antwork como token bearer, con las mismas herramientas y permisos; la página del servidor MCP muestra cómo configurarlo. El CLI solo inicia sesión con el navegador, y por eso no funciona en CI.