¿Cómo funciona la autenticación MCP? Auditoría de la cadena OAuth

Para un servidor MCP remoto protegido, authentication no es una verificación de token. Se trata de una cadena de autorización: el cliente recibe un desafío, descubre metadatos para el recurso protegido exacto, descubre y valida un servidor de autorización, obtiene una identidad de cliente, ejecuta un flujo de código de autorización con PKCE y un indicador de recursos, recibe los ámbitos requeridos y demuestra que el token resultante funciona en el punto final de MCP previsto. Esa respuesta tiene un límite importante. El Especificación de la autorización del MCP actual hace que la autorización sea opcional y aplica su ruta OAuth a los transportes basados en HTTP. En cambio, un servidor local de STDIO debe obtener las credenciales a través de su entorno de acogida u otro mecanismo local. Por lo tanto, iniciar un flujo de navegador para cada conexión MCP no es un defecto razonable. La pregunta operativa no es ¿¿Tengo un token? Es ¿Qué recibos muestran que cada vinculación en esta cadena de autorización en particular está de acuerdo? Una cadena en forma de token puede coexistir con el recurso equivocado, un emisor no confiable, el alcance faltante o una solicitud protegida que aún devuelve 401 . Comienza con el transporte y el primer desafío El Tutorial de autorización de MCP oficial explica el flujo HTTP remoto en etapas. En forma condensada: 1. El cliente envía una solicitud de MCP sin un token. 2. El servidor MCP protegido devuelve 401 Unauthorized con un desafío Bearer WWW Authenticate . 3. El reto apunta a los metadatos de recursos protegidos a través de resource metadata . 4. Dichos metadatos identifican el recurso protegido y uno o más servidores de autorización. 5. El cliente obtiene metadatos del servidor de autorización y valida el emisor y los puntos finales. 6. El cliente obtiene un ID de cliente a través de un mecanismo que el servidor de autorización admite, luego ejecuta el flujo de código de autorización con PKCE y el identificador de recursos MCP. 7. El cliente envía el token de acceso resultante al servidor MCP y observa la solicitud protegida. El primer 401 no es un fracaso en la supresión. Es un recibo de descubrimiento. Un registro útil mantiene el estado HTTP, el esquema de autenticación, la URL de metadatos, el tiempo de observación y el recurso MCP seleccionado. El Znot mantiene el encabezado Authorization , las cookies, el código de autorización, el verificador, el secreto del cliente o el token de acceso. RFC 9728 define los metadatos de recursos protegidos y el conocido patrón de descubrimiento. Su valor de seguridad depende de la autoridad: los metadatos para https://mcp.example/mcp deben describir ese recurso, no un host similar o una URL proporcionada por un servicio no relacionado. Seguir una URL de autorización arbitraria de un cuerpo de error no es equivalente. El servidor de autorización es un papel separado. Un servidor MCP protegido actúa como un servidor de recursos OAuth; el cliente MCP actúa como un cliente OAuth; el servidor de autorización interactúa con el usuario cuando sea necesario y emite tokens de acceso. La confluencia de estas funciones hace que un error común de resolución de problemas parezca plausible: girar un token de servidor de recursos antes de comprobar si el cliente descubrió el emisor correcto. Enlazar el flujo de recursos, emisor, cliente y código Dos URLs merecen una comparación exacta. El primero es el recurso protegido. RFC 8707 define el parámetro de solicitud resource para que un servidor de autorización conozca al destinatario previsto de un token. El borrador actual del MCP requiere el parámetro de recursos tanto en las solicitudes de autorización como en los tokens. Un token de acceso emitido para otra API no es almost valid para el servidor MCP seleccionado. El segundo es el emisor del servidor de autorización. Antes de abrir el navegador, un cliente registra el emisor de metadatos validados del servidor de autorización. Cuando una respuesta de autorización incluye iss , el borrador de MCP actual describe la comparación con ese valor registrado antes de que el cliente envíe el código a un punto final de token. Una desajuste de emisores es una condición de parada, no una razón para probar el mismo código contra ambos puntos finales. El registro de clientes es también una capa explícita. Un cliente puede utilizar un documento de metadatos de ID del cliente, un ID del cliente pre registrado o un camino de registro dinámico soportado. El proyecto actual trata el Registro Dinámico de Clientes como un mecanismo de compatibilidad y no como una suposición universal. Si no existe un mecanismo de registro compatible, el veredicto correcto es registration blocked ; inventar un URI de redirección o reutilizar el ID del cliente de otro producto ocultaría el fallo de interoperabilidad real. PKCE vincula la solicitud de autorización al intercambio de códigos posterior. La auditoría registrará únicamente si el flujo conserva un verificador vinculado, nunca el verificador mismo. Una vinculación faltante se convierte en unsafe flow , incluso si un navegador devuelve un código. Aquí está la forma libre de contenido utilizada para un accesorio saludable: Los nombres de ámbitos son pruebas de configuración, no valores secretos. En un despliegue sensible, todavía pueden revelar capacidades, por lo que solo conservan lo que necesita la decisión de salud y aplican los mismos controles de acceso que otros metadatos operativos. Diagnóstico de la primera capa fallida Una lista de verificación plana produce acciones contradictorias. Si los metadatos de recursos protegidos no están disponibles, la comparación de emisores no tiene información fiable. Si el identificador de recursos es incorrecto, solicitar un alcance más amplio no lo reparará. Por lo tanto, el clasificador utiliza la precedencia y se detiene en la primera capa fallida: El veredicto Pruebas que detuvieron la cadena La próxima acción restringida not applicable Transporte local de estudios Utilice el mecanismo de credencialización local de tiempo de ejecución invalid challenge Falta o no HTTPS resource metadata Repara el reto 401 metadata unavailable Los metadatos de los recursos protegidos no fueron devueltos a 200 Restaurar metadatos; no adivinar el emisor resource mismatch Metadatos o tokens dirigidos a un recurso diferente Corregir la identidad del recurso o solicitar un token vinculado a los recursos issuer mismatch Descubierto o el emisor de devoluciones no está de acuerdo Rechazar el flujo e investigar la autoridad de metadatos registration blocked Ninguna identidad de cliente compatible Configurar un mecanismo de registro compatible unsafe flow El flujo de código de autorización carece de una vinculación PKCE Reiniciar con PKCE step up required La operación actual necesita un alcance no concedido Solicitar únicamente el ámbito de aplicación impugnado token rejected Las obligaciones están de acuerdo, pero la solicitud protegida sigue fallando Clasificar el nuevo reto antes de rotar authorized ready Todos los recibos de autorización están de acuerdo y la solicitud tiene éxito Continuar con la inicialización y las comprobaciones de resultados del MCP El dispositivo suministrado puede reproducirse sin acceso a la red: Su ejecución fechada produjo diez casos, diez veredictos de primera capa, uno authorized ready y secretFieldsStored: 0 . Ese resultado es intencionalmente más estricto que 9 errores y un éxito. Demuestra que la regla de decisión conserva diferencias significativas entre un transporte local, descubrimiento fallido, identidad contradictoria, registro no soportado, flujo de código inseguro, alcance perdido y token rechazado. La regla de la primera capa fallida también limita los retos. metadata unavailable puede justificar un nuevo intento de metadatos limitados. issuer mismatch no debe hacerlo. step up required podrá justificar un nuevo flujo de consentimiento para el ámbito de aplicación impugnado. token rejected requiere leer el nuevo reto porque la expiración, la revocación, el público y el alcance no comparten una reparación. Mantenga el alcance de incremento separado del fracaso de los tokens El actual borrador del MCP recomienda que un servidor incluya el alcance requerido en su desafío WWW Authenticate . El alcance cuestionado para la operación actual es autorizado para dicha operación; no es necesario que sea igual al conjunto completo de metadatos de recursos scopes supported . Esto cambia la decisión del operador. Supongamos que una lectura tiene éxito con files:read , entonces una escritura devuelve 403 y desafíos para files:write . Eso no es prueba de que la tienda de símbolos sea corrupta. Es un estado step up required . El cliente deberá solicitar el permiso faltante con visibilidad humana y conservar los permisos necesarios para otras operaciones. Por el contrario, una solicitud protegida que devuelva 401 después de que el recurso, el emisor, el registro, PKCE y los recibos de alcance estén de acuerdo es token rejected . El siguiente paso seguro es clasificar el nuevo desafío. Presentar repetidamente el mismo símbolo es actividad, no progreso. Rotar todas las credenciales también puede destruir pruebas útiles y interrumpir a clientes sanos. El veredicto de authorized ready sigue siendo estrecho. Dice que el servidor MCP remoto aceptó la cadena de autorización para esta solicitud. No dice: La inicialización del MCP y las negociaciones de capacidad tuvieron éxito; la herramienta seleccionada sigue existiendo o su esquema no ha cambiado; una llamada de herramienta produjo el efecto externo previsto; un efecto secundario es seguro volver a intentarlo después de una pausa de tiempo; la entregable del usuario existe; el servidor de autorización, el cliente y el recurso son de confianza a nivel mundial. Esas son decisiones de salud y seguridad posteriores. Una solicitud protegida exitosa debe trasladar la ejecución a los controles de ciclo de vida del MCP, y luego a la verificación de los efectos de la herramienta y de los resultadosno directamente a agent healthy. Usar el recibo sin recoger credenciales Para las operaciones de producción, almacenar hashes o identificadores estables para el cliente y el recurso seleccionados solo cuando sean necesarios para correlacionar eventos. Registrar sellos de tiempo y versión de especificación porque los metadatos y las reglas del protocolo evolucionan. Mantenga el token crudo, el código, el verificador, el secreto, la cookie, el prompt, los argumentos de la herramienta y los resultados de la herramienta fuera del registro de salud. El artefacto es un clasificador, no una suite de concordancia en vivo. Confia en las observaciones que se le proporcionan. Una implementación real también debe validar TLS, origen de metadatos, redirección de URI, comportamiento del emisor, firmas de tokens o introspección, audiencia, vencimiento y política de implementación. El borrador del MCP fue revisado el 30 de julio de 2026; pin la especificación que implementas y reinicie el fijo cuando ese contrato cambie. El territorio del producto previsto de Sidewisp incluye la accesibilidad de las herramientas, las credenciales vencidas, la pérdida de permisos, el progreso útil y la verificación de resultados. Sidewisp se encuentra actualmente en versión preliminar privada. Sus adaptadores de monitoreo de producción y ejecutor de recuperación no se envían generalmente, por lo que este artículo proporciona una regla de funcionamiento independiente en lugar de afirmar que Sidewisp ya realiza esta auditoría de autorización de MCP. La respuesta práctica a cómo funciona la autenticación MCP? es, por lo tanto, una cadena de recibos de autorización, no una captura de pantalla de token portador. Tratar la primera contradicción como el diagnóstico, aplicar una reparación limitada, y mantener el éxito de la autorización separado del éxito de la herramienta y el resultado final del usuario.