Repository navigation
feat(mcp): keep step-up grants when a refused refresh leads to a new authorization - #2698
mattzcarey wants to merge 5 commits into
Conversation
…thorization The "401 whose token refresh fails" test never checked the scope in the new authorization link. On @modelcontextprotocol/client 2.3.1 that link asks for the server's base scope only and drops the write scope the user granted through step-up, so the write tools fail again and the user is sent back through step-up (#2663). Pin the pkg.pr.new build of modelcontextprotocol/typescript-sdk#2448 and assert the link keeps the write scope. Not for merging as is: the override and blockExoticSubdeps go away once #2448 is released.
|
🔴 agents import sizes: 1 entry point over threshold
Changed exports (5)
How this worksEach runtime export is bundled on its own, minified, and gzipped. Changes smaller than 100 B, or smaller than 1% and 1 KiB, are ignored. Growth over 10% or 5 KiB is marked 🔴. This report is informational and does not fail CI. The workflow artifact contains every measurement. Compared |
agents
@cloudflare/ai-chat
@cloudflare/codemode
hono-agents
@cloudflare/shell
@cloudflare/think
@cloudflare/voice
@cloudflare/worker-bundler
commit: |
…authorization Opt DurableObjectOAuthClientProvider into the SDK's includePreviouslyGrantedScopes (typescript-sdk#2448, preview dfb8587). When a refresh is refused, the new authorization link also asks for the scope the dropped tokens held, so a write scope granted through step-up survives instead of sending the user back through step-up (#2663).
Opts
DurableObjectOAuthClientProviderintoincludePreviouslyGrantedScopesfrom modelcontextprotocol/typescript-sdk#2448, and makes the "401 whose token refresh fails" test check the scope in the new authorization link. The repo pins the pkg.pr.new build of #2448 so this runs against it. Stacked on #2663.Without it, a user grants
workers_scripts:writethrough step-up, the refresh is later refused, the server answers401with its base scope, and the new link asks foraccount:read user:readonly, so the write tools fail again and the user goes back through step-up. With the flag the link asks for all three. With the flag set tofalse, the same assertion fails:Against the preview (
9f7c248): the MCP suite (681 tests), all four client conformance lanes andpnpm run checkpass.Not for merging as is. The
pnpm-workspace.yamloverride points at a preview URL, andblockExoticSubdepsis off because the preview client depends on the preview core by URL. Once #2448 is in a release, drop both and bump@modelcontextprotocol/client; the flag and the test stay.Behaviour changes
invalid_grant), the authorization link for an MCP server also asks for the scopes the dropped tokens held, minusoffline_accessand anything the authorization server does not list inscopes_supported. Asked for once: if the server refuses, the next link asks for the challenged scope alone.