Revisión en profundidad de la especificación de autorización de MCP (edición 2025-03-26)

MCP (Protocolo de Contexto de Modelo) es un estándar abierto que permite a los modelos de IA interactuar con herramientas y servicios externos. Está ampliamente adoptado por la industria. Dado que MCP soporta métodos de transporte basados en HTTP, el Servidor MCP Remoto jugará un papel cada vez más importante en el ecosistema de MCP.

A diferencia del Servidor MCP Local, que permite a cada usuario ejecutar su propia instancia de servidor, el Servidor MCP Remoto requiere que todos los usuarios compartan el mismo servicio de Servidor MCP. Esto plantea el problema central que la Especificación de Autorización de MCP busca resolver: cómo permitir que el Servidor MCP acceda a los recursos del usuario en nombre del usuario.

Este artículo analizará la Especificación de Autorización de MCP en profundidad. Te ayudará a entender los principios de diseño de la especificación de autorización de MCP y algunas direcciones para implementar la Autorización de MCP. Dado que esta Especificación aún está evolucionando, compartiré algunos pensamientos basados en mi experiencia personal en la implementación de Autenticadores, incluyendo:

• Ventajas y limitaciones de OAuth 2.1 como marco de autorización
• Desafíos de los roles duales del Servidor MCP como Servidor de Autorización y Servidor de Recursos
• Complejidad práctica de implementar un Servidor de Autorización completo
• Análisis de escenarios adecuados para autorización delegada por terceros
• Compromisos prácticos del Registro Dinámico de Clientes
• Importancia de definir claramente los límites de recursos del Servidor MCP

Descripción general de la especificación de autorización de MCP#

La Especificación de Autorización de MCP define el proceso de autenticación entre el Servidor MCP (Remoto) y el Cliente MCP.

Creo que basar esta Especificación en OAuth 2.1 es una elección muy razonable. OAuth, como marco de protocolo de autorización, resuelve el problema de cómo permitir a los usuarios autorizar aplicaciones de terceros para acceder a los recursos de usuario en su nombre. Si no estás familiarizado con OAuth, puedes consultar AuthWiki-OAuth para obtener más información.

En el escenario del Cliente MCP y el Servidor MCP, se trata de "usuarios autorizando al Cliente MCP para acceder a recursos de usuario en el Servidor MCP". Los "recursos de usuario en el Servidor MCP" actualmente se refieren principalmente a herramientas proporcionadas por el Servidor MCP o recursos proporcionados por los servicios de backend del Servidor MCP.

Para implementar el proceso de autenticación de OAuth 2.1, el protocolo requiere que un Servidor MCP proporcione las siguientes interfaces para trabajar con el Cliente MCP y completar el proceso de autenticación de OAuth 2.1:

• /.well-known/oauth-authorization-server: Meta datos del servidor OAuth
• /authorize: Punto de autorización, utilizado para solicitudes de autorización
• /token: Punto de token, utilizado para intercambio y actualización de tokens
• /register: Punto de registro de cliente, utilizado para el registro dinámico de clientes

El proceso de autenticación es el siguiente:

La Especificación también especifica cómo el Servidor MCP soporta la autorización delegada a través de servidores de autorización de terceros.

El flujo de ejemplo en la Especificación es el siguiente (del contenido de la Especificación):

En este escenario, aunque el Servidor MCP delega la autorización a un servidor de autorización de terceros, el Servidor MCP sigue actuando como un servidor de autorización para el Cliente MCP. Esto se debe a que el Servidor MCP necesita emitir su propio token de acceso al Cliente MCP.

En mi opinión, este escenario parece más adecuado para manejar situaciones donde el Servidor MCP actúe como intermediario para que el Cliente MCP (usuario) acceda a recursos de terceros (como repositorios de Github), en lugar de que el Servidor MCP actúe como proxy para que el Cliente MCP (usuario) acceda a sus propios recursos.

En resumen, según el protocolo, el Servidor MCP desempeña ambos roles de Servidor de Autorización y Servidor de Recursos en OAuth.

A continuación, discutamos las responsabilidades del Servidor MCP como Servidor de Autorización y Servidor de Recursos.

Servidor MCP como servicio de autorización#

Cuando el Servidor MCP actúa como Servidor de Autorización, significa que el usuario final del Cliente MCP tiene su propia identidad en el Servidor MCP. El Servidor MCP es responsable de autenticar a este usuario final y emitir un token de acceso a este usuario final para acceder a los recursos del Servidor MCP.

Las interfaces relacionadas con la autorización requeridas por la Especificación de Autorización de MCP mencionadas anteriormente significan que el Servidor MCP debe proporcionar una implementación de Servidor de Autorización.

Sin embargo, implementar la funcionalidad del Servidor de Autorización en el Servidor MCP es un desafío significativo para los desarrolladores. Por un lado, la mayoría de los desarrolladores pueden no estar familiarizados con los conceptos relacionados con OAuth. Por otro lado, hay muchos detalles a considerar al implementar el Servidor de Autorización. Si un desarrollador no es del campo relacionado, puede introducir problemas como problemas de seguridad durante la implementación.

Sin embargo, el protocolo en sí no limita al Servidor MCP a implementar solo la funcionalidad del Servidor de Autorización por sí mismo. Los desarrolladores pueden redirigir o proxy estas interfaces relacionadas con la autorización a otros servidores de autorización. Esto no es diferente para el Cliente MCP que el Servidor MCP implementando la funcionalidad del Servidor de Autorización por sí mismo.

Podrías preguntarte, ¿debería este enfoque utilizar el método de autorización delegada de terceros mencionado anteriormente?

Desde mi punto de vista, esto depende principalmente de si los usuarios del servicio de autorización de terceros del que dependes son los mismos que los usuarios finales del Servidor MCP. Esto significa que el token de acceso emitido por el servicio de autorización de terceros será consumido directamente por tu Servidor MCP.

• Si es así, entonces puedes redirigir completamente las interfaces relacionadas con la autorización en tu Servidor MCP a servicios de autorización de terceros.

• Si no, entonces deberías usar el enfoque de autorización delegada de terceros especificado en la Especificación. Necesitas mantener una relación de mapeo entre los tokens de acceso emitidos por el mismo Servidor MCP y los tokens de acceso emitidos por los servicios de autorización de terceros en el Servidor MCP.

Creo que el enfoque de autorización delegada de terceros especificado en el protocolo es algo vago en escenarios de aplicación práctica. El protocolo parece estar permitiendo que terceros ayuden al Servidor MCP a completar el proceso de autorización, pero aún requiere que el Servidor MCP emita su propio token de acceso. Esto en realidad significa que el Servidor MCP aún tiene la responsabilidad de emitir tokens de acceso como Servidor de Autorización, lo cual no es más conveniente para los desarrolladores. Creo que probablemente sea porque los autores del protocolo consideraron que devolver directamente tokens de acceso de terceros al Cliente MCP traería algunos problemas de seguridad (como fugas/abuso, etc.).

Desde mi experiencia, el escenario más adecuado para la autorización delegada de terceros especificada en el protocolo debería ser el escenario de "autorización de usuarios para que el Servidor MCP acceda a recursos de terceros". Por ejemplo, un Servidor MCP necesita acceder a un Repositorio de Github del usuario y desplegar el código del Repositorio en una plataforma de despliegue de código. En este caso, el usuario necesita autorizar al Servidor MCP para acceder a su Repositorio de Github y para acceder a la plataforma de despliegue de código.

En este escenario, el Servidor MCP es un Servidor de Autorización para el Cliente MCP, porque los usuarios finales tienen su propia identidad en el Servidor MCP. El Servidor MCP es un Cliente de terceros para recursos de terceros (en este caso, Github). Necesita obtener la autorización de usuario para acceder a los recursos del usuario en Github. Entre el Cliente MCP y el Servidor MCP, y entre el Servidor MCP y los recursos de terceros, las identidades de los usuarios están separadas. Esto hace significativo mantener una relación de mapeo entre los tokens de acceso emitidos por el mismo Servidor MCP y los tokens de acceso emitidos por los servicios de autorización de terceros en el Servidor MCP.

Por lo tanto, el protocolo de autorización delegada de terceros en el protocolo debería resolver el problema de "cómo los usuarios autorizan al Servidor MCP para acceder a los recursos del usuario en los Servidores de Recursos de terceros".

Servidor MCP como Servidor de Recursos#

Cuando el Servidor MCP actúa como Servidor de Recursos, el Servidor MCP necesita verificar si la solicitud del Cliente MCP lleva un token de acceso válido. El Servidor MCP decidirá si permite al Cliente MCP acceder a recursos específicos basado en el alcance del token de acceso.

Según la definición de MCP, el recurso proporcionado por el Servidor MCP deberían ser herramientas para que el Cliente MCP las use. En este escenario, el Servidor MCP solo necesita decidir si proporciona a los usuarios acceso a ciertas herramientas.

Pero en escenarios del mundo real, estas herramientas proporcionadas por el Servidor MCP también necesitan interactuar con el Servidor de Recursos del propio proveedor de servicios del Servidor MCP. En este momento, el token de acceso obtenido por el Servidor MCP de la solicitud del cliente necesita ser usado para acceder a su propio Servidor de Recursos. En la mayoría de los casos, el Servidor MCP y el Servidor de Recursos detrás de las herramientas son el mismo desarrollador. El Servidor MCP es solo una interfaz proporcionada por sus propios recursos de backend para que el Cliente MCP los use. En este momento, el Servidor MCP puede compartir el mismo token de acceso emitido por un Servidor de Autorización con recursos de backend.

En este caso, en lugar de decir que el Servidor MCP es un Servidor de Recursos, que proporciona herramientas y recursos del propio servicio, es mejor decir que el Servidor de Recursos existente se convierte en un Servidor MCP al proporcionar herramientas para que el Cliente MCP las use.

Incluir recursos proporcionados por su propio Servidor de Recursos en el recurso proporcionado por el Servidor MCP es más por consideración de escenarios del mundo real. Pero personalmente, todavía prefiero que el recurso proporcionado por el Servidor MCP tenga solo herramientas utilizadas por el cliente MCP, y que los recursos de los que dependen las herramientas deberían ser recursos obtenidos por el Servidor MCP de otros Servidores de Recursos (incluyendo de primera parte y de terceros). De esta manera, se pueden cubrir todos los escenarios del mundo real.

Cómo funciona la autorización de MCP#

Después de entender las responsabilidades del Servidor MCP como Servidor de Autorización y Servidor de Recursos, podemos saber cómo funciona específicamente la Autorización de MCP:

Registro Dinámico de Clientes#

La Especificación también define cómo el Servidor de Autorización identifica a los Clientes. OAuth 2.1 proporciona el Protocolo de Registro Dinámico de Clientes, permitiendo al Cliente MCP obtener automáticamente el ID del cliente OAuth sin intervención manual del usuario.

Según la Especificación, el Servidor MCP debe soportar el Protocolo de Registro Dinámico de Clientes de OAuth 2.0. De este modo, el Cliente MCP puede registrarse automáticamente con nuevos servidores para obtener el ID del cliente OAuth. Este enfoque es recomendado en escenarios MCP principalmente porque:

• El Cliente MCP no puede conocer de antemano todos los posibles servidores
• El registro manual causaría problemas para los usuarios
• Hace que la conexión con nuevos servidores sea fluida
• Los servidores pueden implementar sus propias políticas de registro

Sin embargo, desde un punto de vista práctico, tengo algunas reflexiones sobre la aplicación del Registro Dinámico de Clientes en escenarios MCP:

• En prácticas de servicio OAuth prácticas, el Cliente generalmente corresponde uno a uno con una Aplicación de negocio específica. Crear dinámicamente el Cliente puede no ser propicio para gestionar efectivamente los recursos relacionados (usuarios, aplicación, etc.) en los servicios OAuth. Los proveedores de servicios OAuth generalmente esperan tener un control claro sobre los Clientes conectados, en lugar de permitir que cualquier cliente se registre como Cliente a su voluntad.
• Muchos servicios OAuth no recomiendan o permiten a los usuarios crear Clientes dinámicamente, porque esto puede conducir al abuso del servicio. La mayoría de los proveedores de servicios OAuth maduros (como GitHub, Google, etc.) requieren que los desarrolladores registren Clientes manualmente a través de su consola de desarrolladores, y también pueden necesitar proporcionar información detallada sobre la aplicación, URL de retorno, etc.
• Registrar manualmente el Cliente OAuth es en realidad un trabajo único durante el desarrollo, no algo que cada usuario final necesite hacer. No causará una gran carga a los desarrolladores.
• Para el Cliente Público (como aplicaciones nativas, aplicaciones de una sola página, etc.), tenemos formas más seguras de implementar el flujo de OAuth sin registro dinámico. El ID del Cliente combinado con PKCE (Prueba de Clave para Intercambio de Código) puede proporcionar un flujo OAuth suficientemente seguro para el Cliente Público sin crear Clientes dinámicamente.
• Aunque el protocolo señala que utilizar el Registro Dinámico de Clientes puede evitar que los clientes necesiten conocer el ID del Cliente de antemano, de hecho, el Cliente MCP siempre necesita conocer la dirección del Servidor MCP Remoto de antemano. Si es así, especificar el ID del Cliente al pasar la dirección del Servidor MCP Remoto no traerá mucho problema adicional. O también podemos crear una convención para que el Cliente MCP solicite al Servidor MCP el ID del Cliente, lo cual no es una tarea difícil.

Aunque el Registro Dinámico de Clientes proporciona flexibilidad para el ecosistema MCP en teoría, en la implementación práctica, podemos necesitar considerar si realmente necesitamos este mecanismo de registro dinámico. Para la mayoría de los proveedores de servicios, crear y gestionar manualmente el Cliente OAuth puede ser una forma más controlable y segura.

Resumen#

Este artículo analiza profundamente la filosofía de diseño y los desafíos de implementación de la Especificación de Autorización de MCP. Como un marco de autorización basado en OAuth 2.1, esta especificación tiene como objetivo resolver el problema clave de cómo el Servidor MCP Remoto accede a los recursos del usuario en nombre de los usuarios.

A través de una discusión detallada de los roles duales del Servidor MCP como Servidor de Autorización y Servidor de Recursos, así como las ventajas y desventajas de mecanismos como el Registro Dinámico de Clientes y la delegación de autorización de terceros, este artículo brinda reflexiones y sugerencias desde la experiencia personal en la implementación del Autenticador.

Cabe destacar que la especificación de autorización de MCP está todavía en evolución. Como miembro del equipo de Logto, continuaremos prestando atención a los desarrollos más recientes de esta especificación y optimizando continuamente nuestras soluciones de implementación en la práctica para contribuir a la interacción segura entre modelos de IA y servicios externos.