Scopes OAuth
4 scopesEl 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_tokenestá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
6Todo 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.
No hay acceso desatendido
El servidor de autorización ofrece authorization_code y refresh_token, y nada más. Ni client_credentials, ni device code, ni claves de API, ni una UI que pudiera emitir una. Cada token está ligado a un usuario que lo aprobó en un navegador, que es también la razón por la que el CLI no funciona en CI.