Conectar con OAuth y PKCE

OAuth es la forma preferida de conectar un cliente. Un cliente compatible se configura casi por completo por sí solo; tu parte es aprobar la solicitud como el usuario de WordPress adecuado.

Qué hace el cliente

1. Llama al endpoint de MCP y recibe 401 con una cabecera WWW-Authenticate que apunta a los metadatos del recurso protegido.
2. Lee esos metadatos, que nombran a este sitio como su servidor de autorización.
3. Lee los metadatos del servidor de autorización, que enumeran los endpoints de registro, autorización y token.
4. Se registra dinámicamente y recibe un ID de cliente.
5. Abre el endpoint de autorización en un navegador.
6. Intercambia el código devuelto por tokens.

Los pasos 1 a 4 y 6 no requieren nada de ti. El paso 5 sí.

Qué haces tú

El endpoint de autorización exige que hayas iniciado sesión en WordPress. Si no lo has hecho, primero te redirige a la pantalla de inicio de sesión.

A continuación ves una pantalla de consentimiento que nombra al cliente y los ámbitos (scopes) que solicita. Aprobar emite un código de autorización; rechazar devuelve access_denied al cliente y no se concede nada.

Inicia sesión como el usuario cuyas capacidades debe heredar el asistente. Esta es la decisión que importa. Aprobar estando conectado como administrador le da al asistente el alcance de un administrador. Consulta El endpoint de autorización.

PKCE es obligatorio

El servidor exige PKCE con el método S256. Una solicitud sin un code challenge, o que use cualquier otro método, se rechaza con invalid_pkce.

PKCE significa que el cliente genera un verificador secreto, envía únicamente su hash al iniciar el flujo y demuestra la posesión del original al intercambiar el código. Un código de autorización interceptado es inútil sin el verificador.

No hay secreto de cliente. El endpoint de token usa token_endpoint_auth_method: none, lo cual es correcto para clientes públicos y es la razón por la que PKCE no es opcional aquí.

Duración de los tokens

El cliente se actualiza en silencio, de modo que una conexión en funcionamiento sigue funcionando hasta treinta días de actividad sin que hagas nada. Después repite el paso de autorización.

Cada renovación reemplaza ambas credenciales e invalida el par anterior. La autorización subyacente sigue siendo la misma, de manera que las tareas pendientes, el acceso a los resultados y las revisiones no caducadas continúan bajo sus permisos originales. Revocar la autorización detiene ese acceso; iniciar una nueva autorización no transfiere tareas ni aprobaciones anteriores.

Los códigos de autorización se consumen al usarlos —reproducir uno falla.

Los tokens están vinculados

Cada token está vinculado a:

• el cliente al que se emitió;
• el sitio, mediante el ID del blog;
• el recurso, es decir, el endpoint de MCP de este sitio;
• el usuario que lo aprobó;
• los ámbitos (scopes) aprobados.

Un token de un sitio no funciona en otro, y una solicitud de actualización cuyo recurso no coincide se rechaza. Los tokens se almacenan con hash, nunca en texto plano.

Ámbitos (scopes)

El cliente solicita ámbitos; los ves en la pantalla de consentimiento. Existen ocho, en pares de lectura y escritura en cuatro áreas. Aprueba el conjunto más reducido que permita realizar el trabajo —consulta Ámbitos de OAuth.

Los ámbitos por sí solos no conceden nada. Las capacidades del usuario que actúa y las puertas de escritura siguen aplicándose.

Revocar

Reset OAuth en el panel de ajustes de MCP revoca de una vez todos los clientes, códigos y tokens del sitio. Los asistentes conectados dejan de funcionar inmediatamente y deben repetir la autorización.

No hay un botón de revocación por cliente en el panel; el restablecimiento lo es todo o nada. Tenlo en cuenta cuando haya varios asistentes conectados.

Cuándo falla

Ejecuta los diagnósticos del panel de ajustes de MCP; indica explícitamente si la cabecera Authorization llegó.

Siguiente

Conectar un cliente recorre toda la configuración y, a continuación, haz tu primera solicitud de lectura.