[Feature Request] MCP 客户端缺少 OAuth 2.0 支持（PKCE/动态注册/令牌刷新），无法直连强制 OAuth 的远程 MCP 服务器（如 Atlassian Remote MCP）——工程化必需

[MaYale8688]

问题

dsh-mcp-client 目前只支持 stdio / streamable-http 两种传输 + 静态请求头，完全没有 OAuth 2.0 客户端能力（授权码 + PKCE、RFC 8414 discovery、RFC 7591 动态客户端注册、令牌存储与刷新均缺失；源码 lib/index.js 确认，插件 inject 仅 ['tools']）。

而 2026 年官方远程 MCP 服务器基本全部强制 OAuth（Atlassian Remote MCP / mcp.atlassian.com 返回 401 + WWW-Authenticate），DSH 因此无法直接接入任何这类官方 MCP。

复现

1. 在 cordis.patch.yml 配置 mcp.atlassian.com/v1/mcp（streamable-http）
2. 连接被 401 拒绝；静态 header 无法完成授权码流程
3. 必须自建本地桥接 server（本人实测：为绕开此缺口手写了约 600 行桥接：OAuth 授权码 + PKCE + 动态注册 + 令牌刷新 + 工具转发），把"本应内置的能力"搬到了用户侧

期望

按 MCP 规范的 OAuth Authorization 章节（modelcontextprotocol/specification）实现内置 OAuth 2.0 client：

• 授权码 + PKCE（S256）
• RFC 8414 授权服务器发现（.well-known/oauth-authorization-server）
• RFC 7591 动态客户端注册（registration_endpoint）
• 本地回调（localhost redirect）或 Device Flow，浏览器授权
• 令牌持久化（0600）与自动刷新；连接 401 时自动触发授权流程
• 参考实现：@modelcontextprotocol/sdk 1.30 已内置 OAuthClientProvider（本项目依赖中已包含该 SDK），Claude Code 亦同

工程价值

• 企业内部大量官方远程 MCP（Atlassian Jira/Confluence、GitHub、Slack 等）强制 OAuth，DSH 作为工程化 agent harness 无法接入意味着关键业务数据（工单、PR、文档）不可达
• 无内置 OAuth 时每个用户都要自建桥接，安全与维护成本高
• 这是"工程化与实际应用场景"的必备能力，建议优先实现

[Electricitysheep]

MCP 缺 OAuth 2.0（PKCE/动态注册/令牌刷新）——远程 MCP 服务器强制 OAuth 的越来越多（Atlassian 这类），纯静态请求头确实不够工程化。

MCP 接入的工程边界第 9 章有讨论，OAuth 是下一块要补的：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/09-mcp-subagent-workflow.md

[JonZeolla]

To help discovery for English-speaking people and agents, here is a google translate dump of the original post.

Issue
Currently, dsh-mcp-client supports only stdio or streamable-http transport mechanisms alongside static request headers; it completely lacks OAuth 2.0 client capabilities (missing Authorization Code + PKCE flows, RFC 8414 discovery, RFC 7591 dynamic client registration, and token storage/refresh mechanisms; source code lib/index.js confirms that plugin injection is limited to ['tools']).

However, by 2026, official remote MCP servers will essentially mandate OAuth (e.g., Atlassian Remote MCP / mcp.atlassian.com returns 401 + WWW-Authenticate), rendering dsh unable to directly connect to any such official MCPs. Reproduction
Configuring mcp.atlassian.com/v1/mcp (streamable-http) in cordis.patch.yml results in a 401 Unauthorized error; static headers cannot complete the authorization code flow.
One is forced to build a custom local bridge server (I personally wrote ~600 lines of bridging code—handling OAuth auth code, PKCE, dynamic registration, token refreshing, and tool forwarding—to work around this gap), effectively shifting functionality that should be built-in onto the user.
Expectation
Implement a built-in OAuth 2.0 client following the OAuth Authorization section of the MCP specification (modelcontextprotocol/specification):

Authorization Code + PKCE (S256)
RFC 8414 Authorization Server Discovery (.well-known/oauth-authorization-server)
RFC 7591 Dynamic Client Registration (registration_endpoint)
Local callback (localhost redirect) or Device Flow with browser-based authorization
Token persistence (file mode 0600) and automatic refreshing; automatic re-authorization upon receiving a 401 error
Reference implementation: @modelcontextprotocol/sdk v1.30 includes a built-in OAuthClientProvider (this project already depends on this SDK), and Claude Code follows the same pattern.
Engineering Value
Many official remote MCPs used within enterprises (Atlassian Jira/Confluence, GitHub, Slack, etc.) mandate OAuth; the inability of DSH—as an engineering-grade agent harness—to connect means critical business data (tickets, PRs, documentation) remains inaccessible.
Without built-in OAuth, every user must build their own bridge, incurring high security and maintenance costs.
This is an essential capability for "production-grade engineering and real-world use cases"; implementation is highly recommended as a priority.

Also, +1 :)

[weijiafu14]

这个场景现在可以不再自建 OAuth 转发桥。我们已经用 pi2dsh 把原版
pi-mcp-adapter 作为普通 DSH 插件能力包接入，插件仍然自己负责 MCP
transport、OAuth、缓存和刷新；pi2dsh 只把它的公开 Host ABI 翻译到 DSH 的
commands、userQuestions、tools 与模型调用链。

安装仍然只用 DSH 官方插件命令：

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add pi-mcp-adapter

重启后，在标准 .mcp.json 中声明远程服务器（例如 Atlassian 的
https://mcp.atlassian.com/v1/mcp/authv2，auth: "oauth"），然后在 dsh-TUI
或 Web 执行：

/mcp-auth atlassian

刚完成的真实验收不是 mock：Atlassian 授权服务器发现、动态客户端注册、PKCE、
浏览器 localhost 回调、安全凭证存储、MCP 重连与 26 个工具发现全部通过；随后
DeepSeek 在 DSH Web 和 dsh-TUI 中都真实调用了只读的
atlassian_atlassianUserInfo，持久会话日志里的 tool/result 为
isError:false。正常本机回调会自动完成并撤掉粘贴框；只有 SSH/跨机器浏览器无法
访问回调端口时才需要手动粘贴 URL。/pi-mcp logout atlassian 会清除凭证。

这是一条现在即可安装的生态兼容路径，不代表官方 dsh-mcp-client 已被修改；后续
官方原生 OAuth 完善后，两条路径可以按需要替换。

项目与复现步骤：

• https://github.com/weijiafu14/pi2dsh
• https://github.com/weijiafu14/pi2dsh/tree/main/examples/tui-mcp

[lastorder]

+1，同样的场景又踩了一次，补充一个独立复现案例，供跟踪参考。

背景：orion-agent-mcp preset 里配置 @deepseek-ai/dsh-mcp-client 连接
https://mcp.atlassian.com/v1/mcp/authv2（Atlassian 官方 Rovo MCP Server，
streamable-http），用 headers.Authorization 塞静态 Bearer/Basic token。

确认结论：

• 读了 dsh-mcp-client@0.1.1-rc.2 的 lib/types/index.d.ts：StreamableHttpConfig
  只有 headers: Record<string, string>，没有任何 OAuth 相关字段，README 里唯一的
  鉴权示例也是静态 Authorization: Bearer ...。
• 即使换成 Atlassian 官方新支持的 API Token（Basic Auth）鉴权方式，也绕不开需求：
  官方文档明确写了 API Token 认证下 Rovo MCP 只返回 Teamwork Graph 之外的基础
  Jira/Confluence 工具，Rovo Search 相关的语义检索工具不会暴露——
  这块能力被绑定在完整 OAuth 2.1 用户身份上，静态 token 无法替代。
• 所以对需要 Rovo Search 的场景，静态 header 这条路彻底走不通，本质回到本 issue
  描述的"dsh-mcp-client 缺 OAuth transport"这一根因。

看到 @weijiafu14 提到的 pi2dsh + pi-mcp-adapter 路径（/mcp-auth atlassian，
走 PKCE + 本地回调 + 动态客户端注册），准备先按这条路径验证一下作为过渡方案，
同时继续 +1 期待官方 dsh-mcp-client 原生支持 OAuth 2.1（授权码 + PKCE + RFC 8414
discovery + RFC 7591 动态注册 + 令牌持久化/刷新），毕竟这类强制 OAuth 的远程 MCP
（Atlassian、未来更多企业 SaaS）只会越来越多。

[weijiafu14]

感谢你愿意实际验证这条路径。你描述的正是我们完整跑过的场景，不只是确认命令能够挂载：Atlassian 授权服务器发现、动态客户端注册、PKCE、本地浏览器回调、token 安全存储与刷新、MCP 重连、工具目录发现，以及 DSH Agent 的真实工具调用都走完了端到端闭环。

为了避免不同版本的命令或配置细节产生偏差，可以直接让你的 Agent 按仓库里的可复现示例执行：

• 安装与操作步骤：https://github.com/weijiafu14/pi2dsh/tree/main/examples/tui-mcp
• MCP 能力与测试边界：https://github.com/weijiafu14/pi2dsh/blob/main/docs/mcp-compatibility.md

这条路线保留的是原 pi-mcp-adapter 自己的 transport、OAuth、缓存和刷新机制，pi2dsh 只负责把它使用的公开 Pi Host ABI 接到 DSH，所以不是再造一个新的 Atlassian OAuth 转发桥。

如果你的环境里遇到问题，直接在这里继续回复即可。最好附上 DSH、pi2dsh、pi-mcp-adapter 的版本，以及 /mcp-auth 或管理面板里显示的具体错误，我们可以按同一条 E2E 链定位。

[lastorder]

没有遇到问题，pi2dsh + pi-mcp-adapter 路径在我的环境也可以work。

[keejkrej]

又一个独立案例 + 一个零代码过渡方案，今天（2026-10-09）端到端实测跑通，补充给后续跟踪的同学。

1. 服务端证据：规范的 OAuth 已完全就绪

目标服务器 connect.composio.dev/mcp（Composio Connect，7 个 meta-tools）：

• 对无凭据 initialize 返回 401，并携带标准挑战头：
  www-authenticate: Bearer error="unauthorized", resource_metadata="https://connect.composio.dev/.well-known/oauth-protected-resource"
• /.well-known/oauth-protected-resource → 200（RFC 9728）
• /.well-known/oauth-authorization-server → 200：authorization_code + refresh_token、PKCE S256、registration_endpoint（RFC 7591 动态注册）、公共客户端（token_endpoint_auth_methods_supported: ["none"]）

也就是说服务端完全符合 MCP Authorization 规范，缺口 100% 在客户端。

2. 客户端缺口仍然存在（当前桌面版实测）

从 app.asar 里的 dsh-mcp-client 运行时代码确认，streamable-http transport 仍然只传静态 headers、没有 authProvider：

new StreamableHTTPClientTransport(new URL(config.url), { requestInit: { headers: config.headers } })

配置 schema（transport/serverName/url/headers/toolCallTimeoutMs/…）也没有任何 OAuth 字段——与 @lastorder 在 dsh-mcp-client@0.1.1-rc.2 的类型确认一致。

3. 过渡方案：mcp-remote stdio 桥（无需自写桥接代码）

比 600 行自建桥更省事的通用做法——harness 的 stdio transport 原生支持：

- insert:
  - id: mcp-composio
    name: "@deepseek-ai/dsh-mcp-client"
    config:
      serverName: composio
      transport: stdio
      command: /opt/homebrew/bin/mcp-remote
      args:
        - https://connect.composio.dev/mcp
        - "--auth-timeout"
        - "120"
      env:
        HOME: !!js process.env.HOME
        PATH: /opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin

（npm i -g mcp-remote；若 ~/.npm 缓存有 root 属主文件导致 npx EPERM，先 sudo chown -R 修复或直接全局安装。）

实测结果（2026-10-09）：

• 首次运行：mcp-remote 完成 RFC 9728 发现 → RFC 7591 动态注册 → 浏览器授权（授权服务器已有会话时自动放行）→ token 缓存于 ~/.mcp-auth（0600）
• 之后完全静默重连；7 个 meta-tools 正常列出，并真实调用成功（COMPOSIO_SEARCH_TOOLS 返回有效结果）
• 局限与主帖说的本质相同：把“本应内置”的能力放到了用户侧，而且多驻留一个本地进程

4. 期望落地形态（呼应主帖）

• config 增加可选 auth/authProvider 字段，接到打包内 @modelcontextprotocol/sdk 已具备的 OAuth client（项目已依赖该 SDK，边际成本很小）
• 桌面端 localhost 回调；AS 支持 device flow 时提供无浏览器选项
• 收到 401 + resource_metadata 时自动触发授权；凭据 0600 持久化并自动刷新
• 过渡期在官方文档给出 mcp-remote 桥接示例，降低用户侧成本

---

English TL;DR: confirmed on today's desktop build — dsh-mcp-client still wires StreamableHTTPClientTransport with static headers only (no authProvider, no OAuth config fields), while connect.composio.dev/mcp advertises fully spec-compliant OAuth (RFC 9728 metadata, RFC 7591 dynamic registration, PKCE public client). Interim zero-code workaround: run mcp-remote over the harness's stdio transport (config above), verified end-to-end today — browser auth once, token cached in ~/.mcp-auth, silent reconnect afterwards. Native authProvider wiring would close the gap permanently.