MCP OAuth

The MCP server and the Arbol API are separate OAuth resources. A token issued for one audience must not be accepted by the other.

AI client
  |  MCP audience token
  v
Arbol MCP
  |  on-behalf-of exchange
  |  API audience token
  v
Arbol API

Request flow

The client discovers the MCP protected resource and authorization server.
Dynamic client registration creates an approved OAuth client.
A person authorizes the MCP client in the context of their organization.
The client sends the resulting MCP-audience bearer token to the MCP endpoint.
MCP verifies issuer, audience, signature, expiry, organization context, and the MCP access scope.
MCP exchanges that verified token for an API-audience token on the person’s behalf.
MCP calls the generated REST operation with the exchanged token.
The API independently verifies organization and operation permissions.

The deployment must expose and verify:

MCP protected-resource metadata under https://mcp.getarbol.com/.well-known/oauth-protected-resource;
authorization-server metadata from the configured Auth0 custom domain;
a dynamic-client-registration endpoint; and
the downstream API protected-resource metadata at https://api.getarbol.com/.well-known/oauth-protected-resource.

MCP never forwards the incoming MCP token directly to the API.
The exchanged token’s audience is the API, and its scopes are bounded by the delegated user authority.
Organization identity comes from verified token claims, never tool arguments.
Tool execution still receives 401 or 403 from the API when delegated authority is invalid or insufficient.
Token exchange credentials remain server-side and are never returned through MCP content.

This flow is a deployment prerequisite, not a statement that dynamic registration and token exchange are already enabled in production.

⌘I