Secure Authentication for AI Agents using Model Context Protocol

arcade · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: MCP agent authentication and authorization

Arcade identified that MCP servers can call external APIs for agents, but the protocol lacked a secure way for servers to gather third-party credentials such as OAuth bearer tokens without exposing secrets to the MCP client.

Constraints:

• MCP clients may be untrusted code running on user devices.
• OAuth public clients cannot securely store secrets.
• Production MCP servers need OAuth, payment confirmations, API keys, SAML, WebAuthn, audit trails, and fine-grained authorization.
• Credential gathering must preserve least privilege and keep sensitive tokens out of the LLM/client execution path.

Architecture

Arcade proposes URL elicitation: the MCP server requests that the client open a browser URL for sensitive flows, the user authenticates or consents in the trusted browser/auth-provider context, and the trusted server manages tokens, state, scopes, and audit trails. Forms remain for non-sensitive elicitation, while URL mode bypasses the client entirely for credentials.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  A["AI agent"] --> B["MCP client"]
  B --> C["MCP server"]
  C --> D["Browser URL flow"]
  B --> D
  D --> E["Auth provider"]
  E --> F["Token and scope manager"]
  C --> F
  C --> G["External API"]
  F --> G

Components

Data flow

An AI agent invokes an MCP server that needs a third-party API; the server checks whether a valid token exists; if not, it generates secure state and returns a URL elicitation request; the MCP client opens the browser URL without seeing credentials; the user authenticates with the provider; the trusted server validates state, stores tokens, enforces scopes, and then calls the external API on behalf of the agent.

Why this architecture

Arcade chose browser-based URL elicitation because it mirrors battle-tested OAuth security boundaries: the user interacts with a trusted browser and provider, the trusted server handles tokens and scopes, and the untrusted MCP client never sees credentials.

Scale

• The proposal was reviewed by 50+ contributors.
  “security review with 50+ contributors examining attack vectors, CSRF protections, and state management.”article, stated
• Arcade says it already implements secure auth for 100+ integrations.
  “Arcade already implements secure auth for 100+ integrations.”article, stated
• The design covers multiple authorization providers.
  “Real agents need multiple auth providers. URL elicitation handles this elegantly”article, stated

Alternatives considered (roads not taken)

Service account tokens with excessive scopes

Rejected because: This is listed as one of the insecure workarounds developers are forced into without credential gathering.

Pass tokens through the MCP client

Rejected because: It violates least privilege and exposes credentials to untrusted clients.

Use form elicitation for sensitive credentials

Rejected because: Form elicitation flows data through the client and is unsuitable for credentials.

Client-side credential storage

Rejected because: The post calls out token exfiltration risk and public-client secret storage limits.

Patterns

tool-use-orchestration (agent-integration)

MCP servers expose external API tools to agents, but production use requires server-side authorization flows around those tools.

safety-policy-enforcement (security)

URL elicitation enforces security boundaries so credentials bypass the MCP client and remain managed by trusted server/auth-provider components.

human-in-the-loop-gate (authorization)

Sensitive flows route through a browser where the user authenticates, consents, pays, or completes an enterprise identity step.

Tradeoffs

Use URL elicitation for sensitive flows.

Chose direct browser navigation to trusted auth endpoints over forms or client-side token passing.

Rationale: The browser/auth-provider/server path preserves established OAuth-style security boundaries.

Keep token management server-side.

Chose trusted server validates state, stores tokens, and enforces scopes over letting the MCP client handle token state.

Rationale: The MCP client is a public/untrusted client and should have no credential-handling responsibilities.

Gotchas (what bit them)

MCP's client-server authentication did not solve third-party credentials.

Root cause: The protocol lacked a secure mechanism for servers to obtain OAuth tokens for external APIs.

Resolution: Add URL elicitation so servers can redirect users to secure endpoints while credentials stay out of the client.

Existing workarounds violated least privilege or exposed tokens.

Root cause: Developers used service accounts, hardcoded credentials, token passing, or client-side storage to bridge the protocol gap.

Resolution: Move credential gathering to browser URL flows and server-managed token storage.

Form-based elicitation cannot safely handle credentials.

Root cause: Form elicitation sends sensitive data through the client execution context.

Resolution: Use URL mode for OAuth, payments, WebAuthn, and SAML so sensitive flows bypass the client.

Evaluation

The post evaluates the design through security-review criteria: token exposure, least privilege, state validation, CSRF/state management, audit trails, and compatibility with established OAuth patterns.

Metrics: credential exposure · scope enforcement · state validation · audit trails · contributors reviewing attack vectors

Outcomes

• URL elicitation is proposed as a production path for OAuth, payments, WebAuthn, and SAML in MCP.
• Credentials no longer need to pass through the MCP client.
• Arcade reports implementing secure auth for 100+ integrations while waiting for broader MCP ecosystem adoption.

The post frames the design for real agents with multiple auth providers and many production integrations.