You have to tell the user to get the URL out of the browser’s chrome and copy it over, whereas the combined code is in the UI of the helper page. The helper page could just replicate its URL there in the same way, but that’s also a longer string.
It also helps the case where the user can’t copy and paste and would need to type something by hand: the URL host, query parameters, and HTTP URL syntax all add unnecessary baggage when all you really want is the two values. — Justin On Oct 1, 2026, at 10:17 AM, Andrey Kuznetsov <[email protected]> wrote: Hello Justin. Thanks for sharing your approach. In the blog post you mentioned: >Still, it feels weird to tell the user to go copy an entire URL from a browser >they’re in to an app they’re trying to use. As far as I understand, with your idea the user still has to copy some derivative string (the combined code) and transfer it into the possession of the client. Can you elaborate on the benefits of doing so, compared to copying and pasting the entire URL from the redirect URI endpoint? I'm trying to understand the difference, why is it better to copy another string rather than the complete URL which contains both authorization code and state. -- Regards, Andrey Kuznetsov ---------------- To: oauth ([email protected]); Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-oob-authcode-00.txt; 01.10.2026, 01:14, "Justin Richer" <[email protected]>: While working on a CLI client recently, I ran into a problem that I’m sure others have too: when I’m SSH’d in from another system I can’t rely on my browser hitting the redirect_uri reliably. Instead of reaching for the device flow, I came up with a way to make the authorization code flow fit into these constraints a bit better. I wrote up a blog post on the whole thing here : https://medium.com/@justinsecurity/out-of-band-authorization-codes-50a3563bb5af And the first draft of the process is below, based on my implementation. Since this is a process wholly owned by the client, I’m not convinced it actually needs standardization for interoperability sake, but it can probably benefit from the OAuth communities eyes and experience. — Justin Begin forwarded message: From: [email protected]<mailto:[email protected]> Subject: New Version Notification for draft-richer-oauth-oob-authcode-00.txt Date: September 28, 2026 at 7:08:06 PM EDT To: "Justin Richer" <[email protected]<mailto:[email protected]>> A new version of Internet-Draft draft-richer-oauth-oob-authcode-00.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Name: draft-richer-oauth-oob-authcode Revision: 00 Title: Out of Band Authorization Code Delivery for OAuth 2.0 Date: 2026-09-28 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-richer-oauth-oob-authcode-00.txt Status: https://datatracker.ietf.org/doc/draft-richer-oauth-oob-authcode/ HTML: https://www.ietf.org/archive/id/draft-richer-oauth-oob-authcode-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-richer-oauth-oob-authcode Abstract: This client-side process allows clients to use the authorization code grant type without the ability to host the redirect_uri themselves. This process creates a single copyable value that the resource owner can copy from a simple helper page into the waiting client application. The IETF Secretariat , _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
