Skip to content

feat(auth): add RFC 8707 resource parameter to authorize and token requests#10

Open
Zabari wants to merge 1 commit into
warpdotdev:mainfrom
Zabari:warp/oauth-resource-param-main
Open

feat(auth): add RFC 8707 resource parameter to authorize and token requests#10
Zabari wants to merge 1 commit into
warpdotdev:mainfrom
Zabari:warp/oauth-resource-param-main

Conversation

@Zabari
Copy link
Copy Markdown

@Zabari Zabari commented Apr 29, 2026

What

Forwards the AuthorizationManager's base_url (i.e. the MCP server URL) as the OAuth 2.0 resource parameter (RFC 8707, Resource Indicators for OAuth 2.0) on both:

  • the authorization URL produced by get_authorization_url
  • the token-exchange request issued by exchange_code_for_token

This is +13/-1 lines in crates/rmcp/src/transport/auth.rs, plus a small unit test.

Why

Some authorization servers, including Natoma (used for Atlassian's MCP server), require the resource parameter to audience-bind the issued access token. Without it, those servers reject the /authorize request with invalid_request and the browser-based login flow never renders for the user.

This change mirrors the upstream rust-sdk fix from modelcontextprotocol/rust-sdk#651 ("11-25-2025 compliant Auth"), where the same two add_extra_param("resource", ...) calls were threaded through both endpoints. The upstream PR is large because it bundles several other changes (PKCE method verification, SEP-835 scope handling, etc.); this PR is a minimal cherry-pick of just the RFC 8707 part.

Test plan

$ cargo test -p rmcp --features=auth --lib transport::auth
test result: ok. 23 passed; 0 failed

The new test authorize_url_includes_rfc8707_resource_parameter constructs an AuthorizationManager for https://mcp.example.com/v1/sse, calls get_authorization_url, and asserts that the resulting URL has resource=https%3A%2F%2Fmcp.example.com%2Fv1%2Fsse.

End-to-end, this unblocks the Atlassian MCP server OAuth flow in Warp once the pinned rmcp rev is bumped to include this commit.


Co-Authored-By: Oz oz-agent@warp.dev

…quests

Some authorization servers (e.g. Natoma, used for Atlassian's MCP server)
require the OAuth 2.0 `resource` parameter on /authorize and /token to
audience-bind the issued access token (RFC 8707, Resource Indicators for
OAuth 2.0). Without it they reject the authorization request with
`invalid_request` and the browser-based login flow never renders.

Forward the AuthorizationManager's `base_url` (the MCP server URL) as
the `resource` parameter on both:

  * the authorization URL produced by `get_authorization_url`
  * the token-exchange request issued by `exchange_code_for_token`

This mirrors the upstream rust-sdk fix (modelcontextprotocol/rust-sdk
modelcontextprotocol#651, '11-25-2025 compliant Auth') which threads the same parameter
through both call sites.

Adds a unit test asserting that `resource` is present in the generated
authorize URL and equals the manager's base URL.

`cargo test -p rmcp --features=auth --lib transport::auth` => 23 passed.

Co-Authored-By: Oz <oz-agent@warp.dev>
@Zabari
Copy link
Copy Markdown
Author

Zabari commented Apr 29, 2026

Tracking issue filed in warpdotdev/warp: warpdotdev/warp#9462

Pinging @oss-maintainers for review — this PR backports just the RFC 8707 resource parameter from upstream rust-sdk modelcontextprotocol#651, and unblocks Atlassian MCP OAuth login from Warp. Diff is +50/-3 with a new unit test; all 23 auth tests pass locally.

@vorporeal
Copy link
Copy Markdown

i'm working on migrating us to upstream rmcp, which should take care of this. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants