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-50a3563bb5afAnd 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.txtDate: September 28, 2026 at 7:08:06 PM EDTTo: "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]
