Skip to content

Commit f543139

Browse files
committed
Add the device authorization grant to mcp-oauth-console
From MiniMax Code 3.1.2 the Host authenticates every request to the assigned loopback port, so the browser redirect of an authorization-code flow answers 401 and the callback handler never runs. The device authorization grant (RFC 8628) has no redirect at all, so it is not affected; the page now offers it as the recommended method and keeps the PKCE method with the callback URL copied back by hand. Also rebase onto upstream main, document the Agent turns and the two sign-in methods, and tag the row action buttons with data-action so they can be targeted unambiguously.
1 parent 6beeeed commit f543139

6 files changed

Lines changed: 582 additions & 108 deletions

File tree

‎plugins/microbiosis/mcp-oauth-console/README.md‎

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,19 @@ The page lists every MCP server in the MiniMax Code configuration and shows **tw
2121
| Action | What it does |
2222
|---|---|
2323
| Detect | Re-probes the endpoint with a handshake that matches the declared transport, and shows the result in that server's own row |
24-
| Authorize | Runs the authorization-code + PKCE flow: dynamic client registration, browser consent, callback, then a confirmation dialog showing exactly which field will change |
24+
| Authorize | Runs an OAuth sign-in for that server, then a confirmation dialog showing exactly which field will change |
2525
| Confirm write | Patches `mcpServers.<name>.headers.Authorization` in `mcp.json`, backs the file up first, then verifies the token with a real MCP handshake |
2626
| Refresh | Exchanges the stored refresh token for a new access token and writes it back |
2727
| Refresh expiring | Refreshes every stored token that is within 30 minutes of expiry |
2828

29+
## Signing in
30+
31+
Two methods are offered, and the page recommends the first one.
32+
33+
**Device code (recommended).** The server asks the authorization server for a short user code, the page shows it next to a link to the provider's verification page, and the server polls the token endpoint until you approve. There is no redirect, so nothing depends on the browser reaching this Mini App.
34+
35+
**Authorization code + PKCE.** The browser opens the consent page and the provider redirects back to this Mini App's loopback port. **From MiniMax Code 3.1.2 the Host authenticates every request to that port**, so the callback page answers `401` and your handler never runs. The address bar still carries the authorization code, so copy that whole URL back into the page and the flow completes — the callback page itself is never needed.
36+
2937
## How detection works
3038

3139
The probe uses the transport the server declares in the configuration:
@@ -90,6 +98,10 @@ Arguments are passed as an argv array and never through a shell. The URL is the
9098

9199
All durable state lives under `context.dataDir`, the private directory the Host creates for this plugin. Nothing is written outside it except the MCP configuration listed above.
92100

101+
### Agent turns
102+
103+
None. The package declares no `agentAccess`, so it never asks the Agent to run a turn, read a file, or call a tool. Everything happens inside the Node process or in the provider's own page.
104+
93105
### Credentials
94106

95107
Token material stays in the Node process. The page receives metadata only: scope, expiry, and an eight-character SHA-256 fingerprint used to tell two tokens apart. A fingerprint is not reversible and is not usable as a credential. Credentials are never placed in HTML, client JavaScript, log messages, or error responses.
@@ -101,14 +113,15 @@ Token material stays in the Node process. The page receives metadata only: scope
101113
| MiniMax Code | 3.1.6 (Windows) |
102114
| Platform | Windows 11, Node 22 or newer |
103115
| Authorization servers | Hugging Face OAuth (`huggingface.co`), Exa OAuth (`auth.exa.ai`) |
104-
| Verified flows | Dynamic client registration, authorization code + PKCE (S256), authorization code exchange, refresh token exchange, MCP `initialize` handshake after a write |
116+
| Verified flows | Dynamic client registration, device authorization (RFC 8628), authorization code + PKCE (S256), authorization code exchange, refresh token exchange, MCP `initialize` handshake after a write |
105117

106118
Verified end to end against the Hugging Face authorization server and the Hugging Face Inference Endpoints MCP server.
107119

108120
## Known limitations
109121

110122
- The plugin can only manage servers that are already in the MCP configuration, or that you add through the page. It does not discover servers on its own.
111123
- A server that needs a credential but does not declare OAuth cannot be signed in to from the page; the header has to be set by hand.
124+
- The PKCE method needs the callback URL copied back by hand, because the Host guards the loopback port. Use the device code method unless the provider offers nothing else.
112125
- The detection probe checks the handshake. A server may accept an unauthenticated `initialize` and still require a token for tool calls.
113126
- The refresh timer runs while the Mini App is running. A token that expires while the app is stopped is refreshed the next time it starts.
114127

‎plugins/microbiosis/mcp-oauth-console/README.zh-CN.md‎

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,19 @@
2121
| 操作 | 行为 |
2222
|---|---|
2323
| 检测 | 按服务端声明的传输方式重新探测,结果显示在**该服务器自己那一行** |
24-
| 授权登录 | 走完授权码 + PKCE 流程:动态注册客户端、浏览器同意、接收回调,然后弹出确认框,明确告诉你将改动哪个字段 |
24+
| 授权登录 | 为该服务器完成一次 OAuth 登录,然后弹出确认框,明确告诉你将改动哪个字段 |
2525
| 确认写入 | 改写 `mcp.json` 里 `mcpServers.<name>.headers.Authorization`,先备份,再用真实的 MCP 握手验活 |
2626
| 刷新令牌 | 用已存的 refresh_token 换新 access_token 并写回 |
2727
| 刷新即将过期 | 刷新所有距过期不足 30 分钟的令牌 |
2828

29+
## 登录方式
30+
31+
页面提供两种方式,并默认推荐第一种。
32+
33+
**设备码(推荐)**。服务端向授权服务器申请一串短设备码,页面把它和验证页链接一起显示出来;你在授权页确认后,服务端轮询令牌端点直到拿到授权。**全程没有跳转**,因此不依赖浏览器能不能回到本 App。
34+
35+
**授权码 + PKCE**。浏览器打开同意页,授权服务器再跳回本 App 的回环端口。**从 MiniMax Code 3.1.2 起,宿主会对该端口的每个请求做鉴权**,于是回调页会返回 `401`、你的处理器根本不会被执行;但地址栏里仍然带着授权码,把整段 URL 复制回页面即可完成——回调页本身并不需要打开。
36+
2937
## 探测是怎么做的
3038

3139
探针使用服务端在配置里声明的传输方式:
@@ -90,6 +98,10 @@
9098

9199
所有持久状态都放在 `context.dataDir`——宿主为这个插件创建的私有目录。除了上面列出的 MCP 配置,不会写到它以外的地方。
92100

101+
### Agent 回合
102+
103+
没有。本包没有声明 `agentAccess`,因此从不让 Agent 跑回合、读文件或调工具;一切都在 Node 进程内或授权服务器自己的页面里完成。
104+
93105
### 凭据
94106

95107
令牌本体始终留在 Node 进程里。页面只拿到元信息:scope、过期时间,以及一个八位 SHA-256 指纹,用来分辨两个令牌是否不同。指纹不可逆,也不能当凭据用。凭据不会出现在 HTML、客户端 JavaScript、日志或错误响应中。
@@ -101,14 +113,15 @@
101113
| MiniMax Code | 3.1.6(Windows) |
102114
| 平台 | Windows 11,Node 22 及以上 |
103115
| 授权服务器 | Hugging Face OAuth(`huggingface.co`)、Exa OAuth(`auth.exa.ai`) |
104-
| 已验证流程 | 动态客户端注册、授权码 + PKCE(S256)、授权码换令牌、refresh_token 换令牌、写入后的 MCP `initialize` 握手 |
116+
| 已验证流程 | 动态客户端注册、设备码流程(RFC 8628)、授权码 + PKCE(S256)、授权码换令牌、refresh_token 换令牌、写入后的 MCP `initialize` 握手 |
105117

106118
已针对 Hugging Face 授权服务器与 Hugging Face Inference Endpoints MCP 服务器端到端验证。
107119

108120
## 已知限制
109121

110122
- 只能管理已经在 MCP 配置里的服务器,或通过页面新增的服务器;不会自己发现服务器。
111123
- 需要凭证但没声明 OAuth 的服务器无法从页面登录,只能手工配置请求头。
124+
- 授权码方式的回调地址要手工复制回来(宿主对回环端口有鉴权),除非授权服务器不提供设备码流程,否则优先用设备码。
112125
- 探测只验证握手。服务端可能接受未认证的 `initialize`,却在调用工具时才要令牌。
113126
- 续期定时器只在 Mini App 运行时工作。App 停掉期间过期的令牌,会在下一次启动时补刷。
114127

0 commit comments

Comments
 (0)