Provide a login path that works in Workbench against Connect < 2026.06 (legacy token flow and/or configurable redirect URI)

Bắt đầu trong rsconnect/oauth.py, đặc biệt là login_with_device_code() và register_client(), sau đó so sánh các triển khai publisher được tham chiếu trong generateToken.ts và workbench.ts. Xác định đường dẫn xác thực hoặc cấu hình chuyển hướng nào bao phủ tốt nhất các máy chủ Connect cũ trong các phiên được lưu trữ. Hoàn thành khi đăng nhập có một route không phải loopback hoạt động được cho Connect trước 2026.06 mà không bị treo trong Workbench.

Problem

rsconnect login <server> runs an OAuth authorization code flow with a loopback redirect URI (http://127.0.0.1:<port>/callback, rsconnect/oauth.py). In a hosted session — Posit Workbench, a remote container, a cloud IDE — the browser that opens is not on the same host as the CLI listener, so the callback never arrives and the login hangs.

--use-device-code is the current workaround, and posit-dev/posit-dev/rsconnect-python#842 tracks falling back to it automatically. But device code only exists if the target Connect is new enough: the built-in OAuth authorization server gained RFC 8628 device code support in Connect 2026.06. Against an older Connect, login_with_device_code() correctly reports that the server does not support the flow (rsconnect/oauth.py, "Server does not support the device code flow"), and at that point there is no working path at all from a Workbench session. The error message tells the user what happened but leaves them with no route forward.

This is currently blocking agentic publishing from Workbench: see posit-dev/connect#42494 and posit-dev/connect#42503, where the connect-deploy skill was updated to prefer --use-device-code in Workbench. That fix is complete only for Connect >= 2026.06.

Requested change

Two options, not mutually exclusive:

1. Implement the legacy token claim flow as an alternate path

Posit Publisher already does this, and it works against older Connect versions because it polls rather than relying on a redirect:

1. Generate an RSA 2048-bit keypair and a token ID.
2. POST /__api__/tokens with the public key, which returns a claim URL.
3. Show the claim URL to the user.
4. Poll until the token is claimed, then use the private key to sign requests.

See extensions/vscode/src/auth/generateToken.ts in posit-dev/publisher for the reference implementation. rsconnect (R) connectUser() uses the same mechanism, so rsconnect-python is the odd one out here. Because it is poll-based, it needs no reachable callback and works in any hosted environment.

2. Allow the redirect URI to be supplied

Add something like --redirect-uri, or detect Workbench directly, so the authorization code flow can use a browser-reachable callback instead of loopback. In Workbench that URL is derived from RS_SERVER_URL: Workbench exposes a generic OAuth relay at /oauth_redirect_callback that records the authorization code against the state parameter, and /oauth_code?state= hands it back once. Publisher implements exactly this in extensions/vscode/src/auth/oauth/workbench.ts (with RS_SERVER_ADDRESS used for the polling side so the browser session cookie isn't required).

Note that register_client() currently hardcodes "redirect_uris": ["http://127.0.0.1/callback"] during Dynamic Client Registration, so a configurable redirect URI has to be threaded through registration too, and Connect has to accept the non-loopback value.

Longer term, a general mechanism for "use a public callback URL when one is available" is the better answer than every tool detecting Workbench on its own — but the legacy token flow is the pragmatic near-term fix for pre-2026.06 servers.

Related

• posit-dev/rsconnect-python#842 — automatic device code fallback when the loopback callback fails (covers Connect >= 2026.06)
• posit-dev/connect#42494 — connect-deploy skill: guide agents to device code auth in Workbench
• posit-dev/connect#42503 — the skill change itself
• posit-dev/positron#15636

Filed at the request of @mconflitti-pbc.