/.well-known/oauth-authorization-server: descubrimiento del authorization-server
El segundo documento de descubrimiento. Le indica al cliente dónde están los endpoints de OAuth y qué admite este authorization-server.
https://example.com/.well-known/oauth-authorization-serverGET, público, devuelve JSON.
Qué contiene
| Campo | Valor |
|---|---|
issuer |
La URL raíz del sitio, sin barra diagonal final |
authorization_endpoint |
/pom-ai-mcp/oauth/authorize |
token_endpoint |
/pom-ai-mcp/oauth/token |
registration_endpoint |
/pom-ai-mcp/oauth/register |
revocation_endpoint |
/pom-ai-mcp/oauth/revoke |
revocation_endpoint_auth_methods_supported |
none |
response_types_supported |
code |
grant_types_supported |
authorization_code, refresh_token |
code_challenge_methods_supported |
S256 |
scopes_supported |
Los scopes anunciados por este servidor |
token_endpoint_auth_methods_supported |
none |
Leer las restricciones
Cuatro de estos campos constituyen toda la postura de seguridad del flujo, expuesta de antemano:
response_types_supported: code. Solo el flujo de authorization code. No se ofrecen el flujo implícito ni otros flujos.
code_challenge_methods_supported: S256. PKCE es obligatorio y solo se acepta el método SHA-256. Un cliente que envíe plain, o ningún challenge, es rechazado con invalid_pkce.
token_endpoint_auth_methods_supported: none. No hay client secret. Los clientes son públicos, lo que es correcto para asistentes que se ejecutan localmente, y precisamente por eso PKCE no es opcional.
grant_types_supported. Authorization code para obtener tokens, refresh token para renovarlos. Nada más.
Los scopes
scopes_supported enumera los scopes que entiende este servidor. Las conexiones directas al sitio anuncian ocho scopes de sitio; la pasarela de cuentas anuncia sus propios scopes de cuenta. Un cliente usa esto para saber qué puede solicitar; no implica que se le vaya a conceder ninguno de ellos.
La aprobación ocurre en la pantalla de consentimiento, y los scopes son solo una de las cuatro comprobaciones que debe superar una llamada. Consulta OAuth scopes.
El issuer
El issuer es la propia URL raíz del sitio, y coincide con la entrada de authorization_servers en los metadatos del recurso protegido. Los clientes verifican que ambos coincidan antes de confiar en el documento.
Cada sitio es su propio issuer. En multisitio, cada sitio anuncia un issuer distinto y emite tokens que solo funcionan allí.
Es una regla de reescritura
Al igual que el documento del recurso protegido, esta ruta se sirve mediante una regla de reescritura de WordPress.
- Se requieren enlaces permanentes amigables, o devolverá tu página 404.
- Un directorio
.well-knownreal en el disco puede taparlo, en cuyo caso WordPress nunca ve la solicitud.
Si el documento del recurso protegido funciona y este no, sospecha de un archivo físico en esta ruta concreta.
Sitios multilingües
La forma localizada — /es/.well-known/oauth-authorization-server — también responde cuando POM Translate antepone prefijos a las URLs, mientras que la URL canónica sin prefijo sigue siendo la anunciada.
Caché y CORS
Se envía con cabeceras de caché no-store y un tipo de contenido JSON. Las solicitudes de origen cruzado solo se responden para orígenes permitidos, con OPTIONS devolviendo 204.
Una copia en caché tras un cambio de dominio dirige a los clientes hacia endpoints que ya no coinciden con el recurso, lo que produce invalid_resource en el paso del token. Excluye la ruta del almacenamiento en caché de la CDN.
Comprobarlo
Ábrelo en un navegador y confirma que las URLs de los endpoints usan tu host canónico y el mismo esquema que el endpoint MCP. Una discrepancia entre lo que anuncia este documento y aquello con lo que se configuró el cliente es la raíz de la mayoría de los fallos de invalid_resource.
El diagnóstico del panel de ajustes de MCP lo obtiene desde el servidor e informa del estado, el tipo de contenido y si se analizó correctamente como JSON.
Revocar una concesión individual
Envía POST al revocation_endpoint anunciado con la credencial en token y su client_id registrado. Se aceptan tanto codificación JSON como de formulario. Las credenciales de acceso y de refresco coincidentes se revocan juntas. Las credenciales desconocidas o ya revocadas reciben la misma respuesta HTTP 200, sin revelar si existe una concesión. No se usa ningún nonce de cookie de WordPress ni client secret para esta operación del protocolo basada en tokens. Los demás clientes siguen autorizados. Conserva las credenciales en los ajustes de conexión protegidos del cliente.