Autorización en MCP 2026-07-28: comprobación del emisor y cambios en el registro de clientes

Qué es

Estado al 25 de octubre de 2026. Los cambios de autorización de 2026-07-28 afectan a la validación del emisor, al registro y a la pertenencia de las credenciales. Volver a comprobar la especificación de autorización de esa versión, las reglas de registro y los metadatos del servidor de autorización antes del despliegue. Los documentos de metadatos del ID de cliente (CIMD) no se introducen en esta revisión: el registro de cambios de 2025-11-25 ya los recomienda. La nueva revisión declara formalmente obsoleto Dynamic Client Registration (DCR), que se conserva por compatibilidad.

El servidor MCP es el recurso protegido, el cliente MCP obtiene acceso y el servidor de autorización emite tokens. Por tanto, los cambios pueden corresponder a servicios distintos aunque un mismo operador los gestione todos. El marco OAuth de MCP se aplica a los despliegues HTTP; no es el mecanismo de credenciales prescrito para stdio.

Por qué importa

Un flujo de autorización debe permanecer asociado al emisor seleccionado cuando comenzó. De lo contrario, los cambios de endpoints o los registros de cliente ambiguos pueden provocar que se utilicen credenciales con el servidor de autorización equivocado. CIMD también introduce responsabilidades de obtención de documentos y validación de redirecciones; reconocer un identificador de cliente con formato de URL no establece la confianza en la aplicación.

Cómo aplicarlo

• Validar las respuestas de autorización antes de canjear el código. Los clientes registran el emisor obtenido de los metadatos validados del servidor junto con el verificador PKCE del intento de autorización. Los servidores de autorización deberían devolver iss y deben anunciar que lo admiten cuando lo hagan. Los clientes comparan exactamente cualquier iss devuelto con el valor registrado después de decodificar el formato de formulario, sin normalizar la URL. Se rechaza cualquier discrepancia, incluso en las respuestas de error. Si los metadatos anuncian soporte para el parámetro de emisor pero falta iss, rechazar la respuesta; si no se anuncia ni se proporciona, la especificación permite continuar.
• Vincular las credenciales de registro al emisor. Guardar las credenciales de registro previo o de DCR bajo el identificador del servidor emisor. Nunca reutilizarlas con otro emisor. Obtener un registro para el nuevo servidor; si el registro previo no coincide, mostrar un error. Esta regla no convierte un identificador CIMD alojado por el propio cliente en un identificador específico de un emisor: la especificación de registro permite expresamente que ese identificador URL sea portable sin volver a registrarse.
• Seguir las reglas de selección del registro. Preferir el registro previo si está disponible; después, CIMD cuando se anuncie mediante client_id_metadata_document_supported; y, por último, DCR si se admite, como alternativa de compatibilidad. Un documento CIMD utiliza HTTPS con una ruta e incluye client_id, client_name y redirect_uris. Su client_id debe ser igual a la URL del documento; validar el JSON y la redirección solicitada frente al documento.
• Reforzar la obtención de metadatos. Aplicar las defensas documentadas contra la falsificación de solicitudes del lado del servidor al obtener documentos de cliente. Considerar políticas de confianza en dominios. CIMD por sí solo no puede impedir la suplantación con redirecciones a localhost; mostrar el nombre de host de la redirección durante la autorización, tal como se exige.
• Mantener una implementación correcta del DCR anterior. Los clientes deben especificar un application_type adecuado. Las aplicaciones nativas de escritorio, CLI y localhost deberían utilizar native; las aplicaciones remotas de navegador deberían utilizar web. Investigar los fallos de registro en lugar de relajar las comprobaciones de redirección para hacerlos desaparecer.
• Conservar el nivel mínimo de seguridad existente. Verificar el soporte de PKCE en los metadatos, proteger los tokens almacenados y validar que los tokens entrantes estén destinados a este recurso MCP. Las llamadas a API de servicios externos necesitan tokens emitidos por separado para esos servicios. La migración del registro no permite reenviar directamente los tokens recibidos ni eliminar las comprobaciones de consentimiento.

Trampas

No presentar DCR como si ya se hubiera eliminado, ni CIMD como obligatorio en todos los casos: su soporte es una recomendación. Como prueba de aceptación propuesta, probar en preproducción respuestas con un emisor correcto, distinto o ausente, un cambio de emisor y cada vía de registro que se conserve. Comprobar que las respuestas rechazadas nunca lleguen al canje del código. Estas comprobaciones se centran en la conformidad con el protocolo; no constituyen una auditoría de seguridad de un despliegue de autorización concreto.