Summary

  • Justin Richer's 28 September individual Internet-Draft proposes a single copyable value for returning an OAuth authorization code from a browser helper page to a waiting remote client.
  • Its HKDF-and-XOR packaging is not a new security guarantee: the helper origin still receives code and state, and the client still needs its pending request and authorization-server context.

A remote terminal can start an OAuth authorization request without being able to host a redirect address reachable by the user's browser. The browser and the command line end up on opposite sides of a practical gap. draft-richer-oauth-oob-authcode-00 proposes putting a registered helper page on the browser side and one paste operation on the terminal side. The draft was submitted on 28 September 2026 as an individual Internet-Draft with Informational intent. Datatracker lists I-D Exists; it has not become a working-group product, IETF-approved standard or RFC.

The authorization server sends its usual authorization response to the registered helper URI. The page reads code and state, uses HKDF material derived from state together with XOR and a checksum, and shows a combined value. The user copies that value into the waiting client. Because the client kept the original state, it can recover the code and proceed to the ordinary token endpoint. The proposal does not require a new server grant or authorization-server extension beyond registering the helper redirect.

That design simplifies a human action; it does not create end-to-end confidentiality. The draft explicitly disclaims a security improvement over the basic authorization-code grant. The browser-delivered code is still present in a GET request to the helper origin. A static page may avoid keeping server-side session state, but its host, CDN, cache or mirror can encounter the URL parameters. Calling the page static does not turn its delivery chain into an invisible channel.

Nor is the combined string a certificate that the expected authorization server acted. The draft's algorithm can be run by anyone with arbitrary values. The client has to bind the recovered code to the authorization request it actually opened, the state it retained, and the token endpoint it intended to use. A client that cannot retain that state cannot follow the proposed combined-code route. The draft also offers a whole-URL paste when page JavaScript fails; that fallback transfers the original URL parameters, not the same HKDF-combined value.

The proposed value carries code and state, not every authorization-response field. In particular, iss is not carried as an independent response parameter; the draft discusses possibly incorporating it into HKDF's INFO when a client knows the server sends it. RFC 9207 already defines issuer identification as a mix-up countermeasure for clients dealing with multiple authorization servers. This draft neither removes that existing concern nor proves a mix-up for every implementation. The question for a multi-server client is how its existing issuer-binding decision survives this handoff.

RFC 8628's device authorization grant remains another route, with server participation and polling. The new proposal targets a different deployment choice: reuse an authorization-code flow while accommodating a remote client. It is not evidence that device authorization failed, nor an instruction to migrate. The economically attractive part is less server work; the governance cost is that a helper origin and the clipboard become part of the operating path.

Sources