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

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.

Beginne in rsconnect/oauth.py, insbesondere bei login_with_device_code() und register_client(), und vergleiche anschließend die referenzierten Publisher-Implementierungen in generateToken.ts und workbench.ts. Ermittle, welcher Authentifizierungspfad oder welche Redirect-Konfiguration ältere Connect-Server in gehosteten Sitzungen am besten abdeckt. Erledigt ist die Aufgabe, wenn die Anmeldung für Connect vor 2026.06 über eine funktionierende Nicht-Loopback-Route möglich ist, ohne in Workbench hängen zu bleiben.