Skip to content
Last updated

Authentication

Outreach MCP uses OAuth 2.1 with Dynamic Client Registration (DCR) as specified by the MCP Authorization spec and RFC 7591. This is what lets new MCP clients connect to Outreach without an admin first manually registering an OAuth app.

How the Flow Works

  1. Client discovery. Your MCP client fetches .well-known/oauth-authorization-server from the Outreach MCP server endpoint to discover the authorization endpoint, registration endpoint, and supported scopes.
  2. Dynamic registration. Client POSTs to the registration endpoint to receive a client_id (and secret if applicable). No pre-registration with Outreach required.
  3. User authorization. Standard OAuth 2.1 authorization code flow with PKCE. The user signs in through Outreach SSO and consents to the requested scopes.
  4. Token exchange. Client exchanges the auth code for an access token.
  5. Tool calls. Every tool call carries the bearer token; permissions inherit from the authenticated Outreach user's RBAC profile.

Key Implications for Developers

  • No API keys to manage in code. OAuth tokens, not static secrets.
  • No per-call auth. Once connected, all 32 tools work transparently.
  • Permissions inherit from the user. If the user can't delete an opportunity in the Outreach UI, the agent can't either. Profile-level RBAC is enforced on every MCP tool call.
  • Audit trail. Tool calls are attributed to the authenticated user in Outreach's activity history — same as UI actions.
  • Revocation is IDP-controlled. Disabling a user at the IDP immediately revokes all MCP access.

Enterprise Note on DCR

DCR is what enables MCP's "plug and play" agent ecosystem. Enterprise customers who want to restrict which MCP clients can connect (e.g., only corporate Claude Enterprise, not personal Claude.ai) should configure IDP-level controls — group restrictions, device trust, conditional access, or disabling DCR at the authorization server.

Spec References