After sleeping on it, one security consideration came to mind. Many ASs apply different processing rules when a request targets a `localhost` redirect URI. For example, I always ask the user to confirm they intend to proceed with the request, even if other processing rules suggest user consent would not be necessary for that specific interaction. (Following the OAuth for Native Apps BCP <https://www.rfc-editor.org/info/rfc8252/#section-8.6> guidelines for handling client impersonation in §8.6).
If the "helper" page is a public static webpage, then the AS will see a `https://` URL and those additional AS-mediated interactions will not happen. Instead, the helper page will become responsible for those interactions. This doesn't strike me as a vulnerability unto itself; the user will still need to *very explicitly* copy and paste from the helper page to the client - which is itself a form of interaction. However, the shift of responsibility from the AS to the helper page felt worth calling out. Presumably the helper page should have approprate copy / instructions to not do that if the user was not interacting with the client. On Thu, Oct 1, 2026 at 7:18 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] > *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]> > > 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] > To unsubscribe send an email to [email protected] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
