Autenticación con el flujo OAuth de MCP

Los clientes MCP que implementan la especificación de autorización de MCP pueden autenticarse con UiPath automáticamente a través de OAuth 2.0. El cliente realiza el descubrimiento del servidor de autorización, aprovisiona su identidad OAuth, obtiene tokens y los actualiza cuando es necesario. Los usuarios y administradores no necesitan crear aplicaciones OAuth ni gestionar tokens de acceso manualmente.

Por parte del usuario, el único paso manual es iniciar sesión en UiPath Cloud en el navegador. El aprovisionamiento de clientes, la emisión de tokens y la actualización de tokens se gestionan entre el cliente y UiPath.

La implementación de UiPath se basa en la versión 2025-11-28 de la especificación de autorización del protocolo MCP.

Descripción general del flujo de autorización

Cuando un cliente MCP se conecta a un servidor UiPath MCP, el flujo de autorización procede de la siguiente manera:

• El cliente recupera el documento de metadatos de recursos protegidos del servidor.
• Los metadatos identifican los ámbitos OAuth necesarios y el servidor de autorización adecuado.
• El cliente recupera los metadatos del servidor de autorización OAuth.
• En función de las capacidades anunciadas, el cliente establece su identidad utilizando el registro dinámico de cliente (DCR) o un documento de metadatos de ID de cliente (CIMD).
• El usuario es redirigido a UiPath Cloud para iniciar sesión y dar su consentimiento.
• El cliente intercambia el código de autorización resultante por tokens OAuth.
• El cliente utiliza el token de acceso para invocar el servidor MCP y actualiza el token cuando es necesario.

Registro automático de clientes (CIMD y DCR)

UiPath admite dos mecanismos complementarios para establecer la identidad OAuth de un cliente MCP: el registro dinámico de clientes y los documentos de metadatos de ID de cliente. Ambas capacidades se anuncian a través de los metadatos del servidor de autorización OAuth, lo que permite a los clientes compatibles seleccionar el mecanismo adecuado sin necesidad de configuración manual.

Registro de cliente dinámico

El registro dinámico de clientes (DCR), definido por RFC 7591, permite a un cliente MCP registrarse mediante programación. El cliente envía sus metadatos al punto final UiPath /oauth/register, que puede incluir el nombre para mostrar del cliente, las URI de redirección, los tipos de concesión y respuesta compatibles y otros metadatos requeridos por el servidor de autorización.

Si se acepta la solicitud de registro, UiPath devuelve un client_id que representa al cliente registrado a lo largo del flujo de autorización. UiPath transporta y revalida la identidad del cliente durante los pasos posteriores de autorización, intercambio de tokens y actualización de tokens.

DCR es apropiado para clientes que pueden iniciar el registro de forma dinámica pero no pueden alojar un documento de metadatos estable y de acceso público.

El registro de cliente dinámico se considera obsoleto y un recurso alternativo heredado en la especificación de MCP. Se eliminará en el futuro.

Documentos de metadatos de ID de cliente

Los documentos de metadatos de ID de cliente (CIMD) proporcionan una alternativa sin registro. Con CIMD, el cliente utiliza una URL HTTPS como su client_id. La URL apunta a un documento de metadatos que describe el cliente, incluidas sus URI de redirección y otras propiedades relacionadas con la autorización.

En el momento de la autorización, UiPath recupera el documento de metadatos de la URL proporcionada y valida su contenido. Este enfoque tiene varias ventajas:

• No se requiere una solicitud de registro por separado.
• UiPath no necesita mantener un registro persistente para el cliente.
• Los metadatos actuales del cliente pueden obtenerse y validarse cuando se produce la autorización.
• El cliente debe alojar sus metadatos en una ubicación HTTPS estable.

CIMD es particularmente adecuado para clientes que pueden publicar un documento de metadatos estable y de acceso público y desean evitar mantener un registro de cliente OAuth independiente.

Configuración de AI Trust Layer

El flujo de proxy OAuth de MCP se rige por una configuración de AI Trust Layer (AITL), que AgentHub resuelve desde Automation Ops Governance para el par activo (usuario, tenant). Tiene dos propósitos:

• Habilitación de características: la política mcp-dynamic-clients controla si se permite el registro automático de clientes. AgentHub lo vuelve a evaluar en tres puntos: consentimiento, intercambio de tokens y actualización de tokens. El flujo está cerrado ante fallos: a menos que la política resuelta se opte explícitamente (mcp-dynamic-clients = true), la solicitud se bloquea y se muestra al usuario una página que enlaza con el administrador de gobernanza de AITL donde se puede habilitar la característica.
• Lista de dominios permitidos de devolución de llamada: las organizaciones pueden definir una lista de dominios permitidos por organización de devolución de llamada (redireccionamiento) donde se pueden entregar códigos de autorización. Los servidores MCP validan todos los URI de redirección en esta lista de permisos antes de la autorización. Este control en capas, combinado con la puerta de control existente, garantiza que los administradores tengan un control detallado sobre dónde se envían los códigos de autorización. Los URI de redirección se validan adicionalmente por seguridad: se requiere HTTPS a menos que el host sea de bucle invertido, se rechacen los hosts de IP interna y no se permitan fragmentos o información de usuario.

Vinculación de recursos y ámbito

Las sesiones OAuth de MCP están vinculadas al servidor MCP específico para el que fueron autorizadas utilizando indicadores de recursos RFC 8707. Esto significa que un token emitido para un servidor es rechazado por otros servidores, lo que proporciona una capa adicional de seguridad. Algunos clientes MCP (como Microsoft Copilot) aún no admiten la vinculación de recursos y recurren a sesiones con ámbito de tenant en las que una única autorización otorga acceso a todos los servidores MCP dentro del tenant.

Clientes compatibles

La autenticación del servidor MCP de UiPath es totalmente compatible con la especificación MCP.

Autenticación alternativa: para los clientes que aún no admiten completamente el flujo OAuth de MCP, puedes autenticarte utilizando tokens de acceso personal, aplicaciones externas o inicio de sesión interactivo.

Para obtener orientación sobre la elección del método de autenticación correcto, consulta Autenticación del servidor MCP.