I think it’s important to keep the “whole URL” as an important fallback. If the HKDF is unavailable or if capturing the full callback URL is just easier, go for it. I was specifically seeing what I could do to avoid that behavior though and give the user one short value to paste in to the terminal.
— Justin On Oct 1, 2026, at 12:27 AM, Max Gerber <[email protected]> wrote: I've also ran into this problem, and I've also used CLI OAuth clients that ask for the entire redirect URL to be pasted in on failure so they can pull out the `code` and `state` params (Claude Code does this with `claude mcp login $server --no-browser` - ref<https://code.claude.com/docs/en/mcp#:~:text=claude%20mcp%20login%20detects,local%20browser%20is%20detected.>). So I like the premise and I really like the "OOB Auth Code" naming to describe the setup, but I'm not sure if the complexity of the HKDF-based scheme is right for me personally. I haven't had issues copying and pasting the whole URL back to my terminal (which is already a single value). To your point on the UX of asking people to copy the URL around being a little janky - a helper page could also base64 encode the entire URL for copy/paste transport, or base64 encode a JSON object containing {"code":"...", "state":"..."} and be off to the races. Also to your point - the entire process is owned by the client. If your usecases are different and HKDF / generating a short copyable value is important, who am I to disagree? On Wed, Sep 30, 2026 at 1:14 PM Justin Richer <[email protected]<mailto:[email protected]>> wrote: 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]
