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]
