UiPath Documentation
orchestrator
latest
false
Orchestrator user guide

Authenticating with the MCP OAuth flow

MCP clients that implement the MCP Authorization specification can authenticate with UiPath automatically through OAuth 2.0. The client performs authorization-server discovery, provisions its OAuth identity, obtains tokens, and refreshes them when necessary. Users and administrators do not need to create OAuth applications or manage access tokens manually.

From the user's side the only manual step is logging into UiPath Cloud in the browser. Client provisioning, token issuance, and token refresh are handled between the client and UiPath.

The UiPath implementation is based on the MCP protocol authorization specification version 2025-11-28.

Authorization flow overview​

When an MCP client connects to a UiPath MCP Server, the authorization flow proceeds as follows:

  • The client retrieves the Server's Protected Resource Metadata document.
  • The metadata identifies the required OAuth scopes and the appropriate authorization server.
  • The client retrieves the OAuth Authorization Server Metadata.
  • Based on the advertised capabilities, the client establishes its identity using Dynamic Client Registration (DCR) or a Client ID Metadata Document (CIMD).
  • The user is redirected to UiPath Cloud to sign in and provide consent.
  • The client exchanges the resulting authorization code for OAuth tokens.
  • The client uses the access token to invoke the MCP Server and refreshes the token when necessary.

Automatic client registration (CIMD and DCR)​

UiPath supports two complementary mechanisms for establishing an MCP client's OAuth identity: Dynamic Client Registration and Client ID Metadata Documents. Both capabilities are advertised through the OAuth Authorization Server Metadata, allowing compatible clients to select the appropriate mechanism without requiring manual configuration.

Dynamic Client Registration​

Dynamic Client Registration (DCR), defined by RFC 7591, allows an MCP client to register itself programmatically. The client submits its metadata to the UiPath /oauth/register endpoint, which can include the client's display name, redirect URIs, supported grant and response types, and other metadata required by the authorization server.

If the registration request is accepted, UiPath returns a client_id that represents the registered client throughout the authorization flow. UiPath carries and revalidates the client identity during subsequent authorization, token exchange, and token refresh steps.

DCR is appropriate for clients that can initiate registration dynamically but cannot host a stable, publicly accessible metadata document.

Dynamic Client Registration is considered deprecated and a legacy fallback in the MCP specification. It will be removed in the future.

Client ID Metadata Documents​

Client ID Metadata Documents (CIMD) provide a registration-free alternative. With CIMD, the client uses an HTTPS URL as its client_id. The URL points to a metadata document that describes the client, including its redirect URIs and other authorization-related properties.

At authorization time, UiPath retrieves the metadata document from the supplied URL and validates its contents. This approach has several benefits:

  • No separate registration request is required.
  • UiPath does not need to maintain a persistent registration record for the client.
  • The client's current metadata can be obtained and validated when authorization occurs.
  • The client must host its metadata at a stable HTTPS location.

CIMD is particularly suitable for clients that can publish a stable, publicly accessible metadata document and want to avoid maintaining a separate OAuth client registration.

AI Trust Layer configuration​

The MCP OAuth proxy flow is governed by an AI Trust Layer (AITL) configuration, which AgentHub resolves from Automation Ops Governance for the acting (user, tenant) pair. It serves two purposes:

  • Feature enablement: The mcp-dynamic-clients policy toggle controls whether automatic client registration is allowed. AgentHub re-evaluates it at three points — consent, token exchange, and token refresh. The flow is fail-closed: unless the resolved policy explicitly opts in (mcp-dynamic-clients = true), the request is blocked and the user is shown a page linking to the AITL Governance admin where the feature can be enabled.
  • Callback domain allow list: Organizations can define a per-organization allow list of callback (redirect) domains where authorization codes can be delivered. MCP Servers validate all redirect URIs against this allow list before authorization. This layered control, combined with the existing governance gate, ensures administrators have fine-grained control over where authorization codes are sent. Redirect URIs are additionally validated for safety: HTTPS is required unless the host is loopback, internal-IP hosts are rejected, and fragments or userinfo are not permitted.

Resource binding and scope​

MCP OAuth sessions are bound to the specific MCP server they were authorized for using RFC 8707 Resource Indicators. This means a token issued for one server is rejected by other servers, providing an additional layer of security. Some MCP clients (such as Microsoft Copilot) do not yet support resource binding and fall back gracefully to tenant-scoped sessions where a single authorization grants access to all MCP servers within the tenant.

Supported clients​

UiPath MCP Server authentication is fully compliant with the MCP specification.

Alternative authentication: For clients that do not yet fully support the MCP OAuth flow, you can authenticate using Personal access tokens, External applications, or Interactive login.

For guidance on choosing the right authentication method, see MCP Server authentication.

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated