Skip to content

feat(webfetch): add RFC 9728 auth flow and harden OAuth handling#22096

Draft
irvinebroque wants to merge 2 commits intoanomalyco:devfrom
irvinebroque:bib/rfc-9728-support
Draft

feat(webfetch): add RFC 9728 auth flow and harden OAuth handling#22096
irvinebroque wants to merge 2 commits intoanomalyco:devfrom
irvinebroque:bib/rfc-9728-support

Conversation

@irvinebroque
Copy link
Copy Markdown

@irvinebroque irvinebroque commented Apr 12, 2026

Issue for this PR

Closes #22095

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

This PR adds OAuth-based authentication to webfetch.

Note — 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. But this does add quite a lot.

When webfetch hits a protected resource, it can now:

  • parse WWW-Authenticate
  • discover protected resource metadata via RFC 9728
  • discover authorization server metadata via RFC 8414
  • run OAuth authorization code + PKCE
  • fall back to device authorization when browser launch fails and the authorization server supports it
  • run device authorization explicitly in headless mode for opencode run
  • store and reuse credentials, including refresh-token based renewal
  • retry the original request with a bearer token using redirect: "error" to avoid forwarding credentials to redirect targets

It also adds a dedicated webfetch_auth permission, documents the new auth module, extends the auth timeout so MFA / OTP / device flows do not inherit the normal short fetch timeout, and surfaces the auth UX in the TUI, desktop app, ACP, and headless run mode.

Problem

webfetch can fetch public URLs, but it had no way to complete standards-based OAuth discovery and authentication for protected resources. A 401/403 response would just fail, even when the server advertised an RFC-compliant auth path.

There was also no clear policy for non-interactive environments. A browser-first flow is the best default for interactive clients, but opencode run needs a deterministic device-code path, and the implementation should not guess that from environment variables.

What Changed

New auth module

Added a new packages/opencode/src/auth/ webfetch auth module.

Considered trying to reuse bits that already exist — but seemed invasive and there wasn't a clear existing abstraction I found in opencode to build off. Could imagine the pieces below either being replaced by using another library, or refactored into a shared implementation.

webfetch integration

Updated packages/opencode/src/tool/webfetch.ts to:

  • reuse stored credentials before the initial request
  • refresh expired OAuth credentials before request injection when possible
  • trigger interactive auth on 401 responses and on 403 responses that include WWW-Authenticate
  • keep the existing Cloudflare challenge fallback that retries with User-Agent: opencode
  • use a separate longer timeout budget for interactive auth so MFA / OTP / device flows can complete
  • emit permission metadata and device-code metadata so clients can present the auth flow clearly

How did you verify your code works?

Tested (mostly with TUI) giving OpenCode URLs that are protected by OAuth, and ensuring that the flow works end-to-end. Still need to do more to test the Desktop app and headless modes.

Screenshots / recordings

CleanShot 2026-04-11 at 17 05 17@2x CleanShot 2026-04-11 at 17 05 29@2x CleanShot 2026-04-11 at 17 05 45@2x CleanShot 2026-04-11 at 17 05 56@2x

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

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.

[FEATURE]: RFC 9728 support for webfetch (OAuth server discovery, access protected resources)

1 participant