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]> 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]
> *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]
