Repository navigation
[FEATURE]: RFC 9728 support for webfetch (OAuth server discovery, access protected resources) #22095
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
When the webfetch tool fetches a URL that returns 401 or 403 with a WWW-Authenticate: Bearer header, there is no way to authenticate. The request fails.
Instead, support RFC 9728 and RFC 8414 — sending the user through an OAuth flow. This allows Opencode users to easily access resources protected behind auth (ex: internal tools, APIs, or anything you might give your agent a URL to, that is behind auth.
OpenCode already implements this discovery flow for MCP servers — as it is required by the MCP specification. But webfetch doesn't benefit from it.
What this adds
On a 401/403 with a WWW-Authenticate header, webfetch would:
- Parse the
WWW-Authenticatechallenges (RFC 9110 Section 11.6.1) - Discover the resource metadata via
/.well-known/oauth-protected-resource(RFC 9728) - Discover the authorization server metadata via
/.well-known/oauth-authorization-server(RFC 8414) - Run an OAuth authorization code + PKCE flow (RFC 7636), falling back to device code (RFC 8628)
- Store credentials and retry the request with a Bearer token
Why
This unblocks webfetch from working with any OAuth-protected API that advertises standard discovery metadata. It also aligns webfetch with how MCP server auth already works, reusing the same RFC-based discovery path.
Related issues
None of these are duplicates — they all target MCP server connections or LLM provider APIs, not the webfetch tool.
| Issue | Relation |
|---|---|
| #7228 | MCP OAuth fails to follow authorization_servers from protected resource metadata. Same RFCs (9728/8414), different integration point (MCP vs webfetch). Closed as completed. |
| #9013 | WebFetch User-Agent causes 401 from corporate proxies. Related symptom (webfetch + auth failure), but the ask is a static header override, not an OAuth flow. |
| #9711 | GitLab OAuth token not auto-refreshed on 401. Same detect-401-and-retry pattern, but for a specific LLM provider, not arbitrary URLs via webfetch. |
| #6088 | Header-based credential injection for OpenCode's server mode. Related concept (injecting auth), but different scope (server API keys, not webfetch to external sites). |
Scope
- New module:
src/auth/with discovery, flow, credential store, and WWW-Authenticate parser - Change to
src/tool/webfetch.tsto call into the auth module on 401/403 - tests covering RFC compliance, SSRF protection, and token lifecycle
I have a draft pull request that I will post and link to. Not at all wedded to the implementation — totally fine if maintainers want to discard it and start over. Have tried to keep it conformant with the style of the Opencode codebase, and minimally invasive as I could.
Activity
github-actions commentedon Jul 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.