[akos-zsolt-toth]

Proposes an RFD for authorizing Clients to remote Agents with OAuth, so that a returning user is recognised on a new connection instead of having to log in again.

Problem

ACP's agent and terminal authentication methods assume a local Agent, which keeps credentials where any later connection can find them. A remote Agent serving many users has no such shared store: it can only recognise a returning user if the Client presents something, and ACP defines nothing for that.

Today a remote Agent signs users in with a URL-mode elicitation inside auth/login. Before login there is no authenticated user, so the result is bound to that elicitation and that connection, and must not be applied to another one (#2641). That rule is correct, but it means every reconnect is a fresh interactive login. The remote transport RFD doesn't cover this either: Clients only need to keep cookies for the duration of a connection.

Proposal

• A standard oauth authentication method type. It points at the Agent's Protected Resource Metadata (RFC 9728).
• A Client capability, capabilities.auth.oauth. Supplying it commits the Client to running the flow, storing and refreshing tokens per Agent resource, and presenting them on every connection. Agents only advertise the method to Clients that supply it, as with terminal.
• The flow follows MCP's authorization spec: discovery, OAuth 2.1 with PKCE, RFC 8707 resource indicators, and optionally the device grant for Clients without a browser. The Client then reconnects with the token, the same way terminal login ends with a reconnect. No credential travels in an ACP message.
• How the token is presented:
  • Authorization: Bearer on Streamable HTTP, and on the WebSocket upgrade where the Client can set headers.
  • For browsers, which can't set headers on a WebSocket: a single-use connect ticket, valid for at most 60 seconds, in the upgrade URL.
• Failures:
  • HTTP gets 401 with WWW-Authenticate: Bearer resource_metadata=….
  • On WebSocket the Agent accepts the upgrade and then closes it with code 4401, because a browser can't read the response to a failed upgrade.
• URL-mode elicitation login stays as the fallback for Clients without the capability. On connections authorized this way, the stronger same-user elicitation check applies.

The FAQ covers the alternatives considered (an Agent-issued credential after URL login, persisting cookies, and MCP-style discovery via 401 only) and the open questions.

Relationship to existing work

• Builds on the remote transport RFD (streamable-http-websocket-transport). It could become a section of that RFD if the authors prefer.
• Consistent with docs(protocol): clarify agent login flow and auth state #2624, which leaves it to the Agent whether a login outlasts the connection, and with docs(protocol): scope the URL elicitation user check to authenticated users #2641's connection binding for pre-login elicitations.
• Keeps the split MCP uses: OAuth for the Client's own authorization to the server, elicitation for the server getting access to third-party services.

Changes

• docs/rfds/remote-oauth-authorization.mdx: the new RFD, from docs/rfds/TEMPLATE.
• docs/docs.json: adds the RFD at the end of the Draft navigation group.

Formatted with Prettier.

Looking for a champion. Happy to move the discussion to Zulip.

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit caac403.

Approve preview