Autenticação com o fluxo OAuth do MCP

Os clientes MCP que implementam a especificação de Autorização de MCP podem se autenticar com a UiPath automaticamente por meio do OAuth 2.0. O cliente realiza a descoberta do servidor de autorização, provisiona sua identidade OAuth, obtém tokens e os atualiza quando necessário. Usuários e administradores não precisam criar aplicativos OAuth ou gerenciar tokens de acesso manualmente.

Do lado do usuário, a única etapa manual é fazer login no UiPath Cloud no navegador. O provisionamento de clientes, a emissão de tokens e a atualização de tokens são tratados entre o cliente e a UiPath.

A implementação da UiPath é baseada na especificação de autorização do protocolo MCP versão 2025-11-28.

Visão geral do fluxo de autorização

Quando um cliente MCP se conecta a um Servidor MCP UiPath, o fluxo de autorização prossegue da seguinte forma:

• O cliente recupera o documento Metadados de Recurso Protegido do Servidor.
• Os metadados identificam os escopos do OAuth necessários e o servidor de autorização apropriado.
• O cliente recupera os metadados do Servidor de Autorização OAuth.
• Com base nos recursos anunciados, o cliente estabelece sua identidade usando o Registro dinâmico de cliente (DCR) ou um Documento de metadados de ID do cliente (CIMD).
• O usuário é redirecionado para o UiPath Cloud para fazer login e fornecer consentimento.
• O cliente troca o código de autorização resultante por tokens do OAuth.
• O cliente usa o token de acesso para invocar o Servidor MCP e atualiza o token quando necessário.

Registro automático do cliente (CIMD e DCR)

A UiPath é compatível com dois mecanismos complementares para estabelecer a identidade OAuth de um cliente MCP: Registro dinâmico do cliente e Documentos de metadados de ID do cliente. Ambos os recursos são anunciados por meio dos metadados do servidor de autorização OAuth, permitindo que os clientes compatíveis selecionem o mecanismo apropriado sem exigir configuração manual.

Registro do cliente dinâmico

Registro de cliente dinâmico (DCR), definido pelo RFC 7591, permite que um cliente MCP registre-se programaticamente. O cliente envia seus metadados para o ponto de extremidade /oauth/register da UiPath, que pode incluir o nome de exibição do cliente, URIs de redirecionamento, tipos de concessão e de resposta compatíveis e outros metadados exigidos pelo servidor de autorização.

Se a solicitação de registro for aceita, a UiPath retorna um client_id que representa o cliente registrado em todo o fluxo de autorização. A UiPath carrega e revalida a identidade do cliente durante as etapas subsequentes de autorização, troca de tokens e atualização de tokens.

O DCR é apropriado para clientes que podem iniciar o registro dinamicamente, mas não podem hospedar um documento de metadados estável e acessível ao público.

O Registro de cliente dinâmico é considerado obsoleto e um fallback legado na especificação MCP. Ela será removida no futuro.

Documentos de metadados do ID do cliente

Os Documentos de metadados do ID do cliente (CIMD) fornecem uma alternativa sem registro. Com o CIMD, o cliente usa um URL HTTPS como client_id seu. O URL aponta para um documento de metadados que descreve o cliente, incluindo seus URIs de redirecionamento e outras propriedades relacionadas à autorização.

No momento da autorização, a UiPath recupera o documento de metadados do URL fornecido e valida seu conteúdo. Essa abordagem tem vários benefícios:

• Nenhuma solicitação de registro separada é necessária.
• A UiPath não precisa manter um registro de registro persistente para o cliente.
• Os metadados atuais do cliente podem ser obtidos e validados quando a autorização ocorre.
• O cliente deve hospedar seus metadados em um local HTTPS estável.

O CIMD é particularmente adequado para clientes que podem publicar um documento de metadados estável e acessível ao público e desejam evitar manter um registro de cliente OAuth separado.

Configuração da AI Trust Layer

O fluxo de proxy OAuth do MCP é governado por uma configuração do AI Trust Layer (AITL), que o AgentHub resolve a partir da Governança do Automation Ops para o par de intervenção (usuário, tenant). Ele serve a dois propósitos:

• Habilitação de funcionalidades: a alternância da política mcp-dynamic-clients controla se o registro automático do cliente é permitido. O AgentHub o reavalia em três pontos — consentimento, troca de tokens e atualização de tokens. O fluxo é fechado com falha: a menos que a política resolvida opte explicitamente por (mcp-dynamic-clients = true), a solicitação é bloqueada e o usuário vê uma página que faz ligação com o administrador do AITL Governança onde a funcionalidade pode ser habilitada.
• Lista de permissões de domínio de retorno de chamada: as organizações podem definir uma lista de permissões por organização de domínios de retorno de chamada (redirecionamento) onde os códigos de autorização podem ser entregues. Os servidores MCP validam todos os URIs de redirecionamento em relação a esta lista de permissões antes da autorização. Esse controle em camadas, combinado com a porta de governança existente, garante que os administradores tenham controle refinado sobre para onde os códigos de autorização são enviados. Os URIs de redirecionamento também são validados para segurança: HTTPS é necessário, a menos que o host seja loopback, os hosts de IP internos são rejeitados e fragmentos ou informações do usuário não são permitidos.

Associação e escopo do recurso

As sessões MCP OAuth são vinculadas ao servidor MCP específico para o qual foram autorizadas usando os Indicadores de recurso RFC 8707. Isso significa que um token emitido para um servidor é rejeitado por outros servidores, fornecendo uma camada adicional de segurança. Alguns clientes MCP (como o Microsoft Copilot) ainda não são compatíveis com a associação de recursos e retornam graciosamente a sessões com escopo de tenant, onde uma única autorização concede acesso a todos os servidores MCP dentro do tenant.

Clientes suportados

A autenticação do Servidor MCP da UiPath é totalmente compatível com a especificação MCP.

Autenticação alternativa: para clientes que ainda não são totalmente compatíveis com o fluxo OAuth do MCP, você pode autenticar usando tokens de acesso pessoal, Aplicativos externos ou Logon interativo.

Para obter orientação sobre como escolher o método de autenticação correto, consulte Autenticação do servidor MCP.