Summary

  • draft-richer-oauth-oob-authcode-00 turns an authorization code and client-held state into one copyable value for clients that cannot receive a browser redirect; it is an individual Internet-Draft, not an adopted OAuth result or RFC.
  • The helper page uses HKDF, XOR and a three-byte checksum so the waiting client can reconstruct the code with its stored state. The draft explicitly says this adds no security beyond the basic code grant.
  • A successful paste is only a transfer and reconstruction receipt. Issuer handling, redirect integrity, PKCE or client authentication, token acceptance, resource authorization and observed service remain separate.

The helper never becomes the client

A command-line client on a remote host can open an authorization URL in the user’s browser but cannot necessarily host the callback the browser can reach. Revision 00 keeps the authorization-code grant and registers a static helper page as the redirect URI. The authorization server returns code and state to that page. JavaScript turns them into one combined code, the user copies it, and the original client recovers the authorization code.

The authorization server does not participate in the new construction. It sees the usual request and later the usual token request. The helper does not receive a secret from the client, maintain server-side state or call the token endpoint. Its contribution is narrower: make it harder for a person to swap or damage two separate values while moving them between devices or terminals.

That is a useful usability result. It is not a new grant type, an authenticated callback to the client or a completed authorization.

What the checksum actually says

The construction names its layers precisely. The helper encodes the authorization code as C. It derives a keystream KS from UTF-8 state, an empty salt and an agreed INFO value, with output the same length as C. It computes E = C XOR KS. It then takes the first three bytes of SHA256(C) as T, base64url-encodes T and E separately without padding, and concatenates them into CC.

The client reverses the operation with the state it retained. If the recomputed three-byte checksum differs, it fails. Values no longer than the four checksum characters must be discarded. If a wrong state yields a different recovered value, the token endpoint should reject the resulting code.

This is not an authorization-server MAC. The checksum is derived from the recovered code, not from a key known only to the authorization server. Anyone can use the static page to form arbitrary combined values. A matching checksum therefore says that reconstruction under the chosen state produced a self-consistent code-shaped value. It does not name who created it, prove which browser session carried it or guarantee that the token endpoint will accept it.

The URL remains a custody event

The draft is candid about the browser path. code and state arrive as query parameters in the helper-page GET. The server, CDN, mirrors and caches involved in serving that page can receive them. HKDF is performed after that exposure. The code was also present in the browser before the user copied anything.

The combined string does not protect a client when both code and state are stolen. Nor does it suit a client that discarded its state and expected the callback to reconstruct the request. If JavaScript cannot run, the proposed fallback is to copy the entire helper URL; that path directly transfers code and state and does not use HKDF at all.

Another parameter disappears. The procedure combines only code and state, dropping iss. The draft suggests that an issuer value could be used as INFO only where the client knows the authorization server returns it. That makes issuer handling an explicit deployment receipt rather than a property of seeing one paste succeed.

The rest of OAuth still happens

RFC 6749’s code binding, redirect and token-endpoint rules remain in force. PKCE, where used, still requires the client to prove the verifier corresponding to the challenge. Client authentication, redirect matching, code lifetime and one-time use are not replaced by the short checksum. RFC 9700’s current threat guidance does not move into the helper string by implication.

The device authorization grant in RFC 8628 solves another operational shape: the authorization server issues a device code and the client polls a token endpoint. The new draft deliberately avoids that server-side grant and its polling. Fewer round trips and one registration may be attractive, but those savings are not evidence that the two flows have identical security, recovery or observability.

Lu Heng’s Minimum Initial Specification supplies the right discipline. The common mechanism should do one interoperable job: reconstruct the code with fewer human transcription errors. Running-Code Primacy then asks what the client, token endpoint and resource server actually observed. The reality layers must not be compressed because the user saw only one string.

Sources and limits

These sources do not prove OAuth working-group adoption, IETF consensus, RFC publication, implementation, interoperability, deployment, a completed login, token issuance, attack, mitigation success or resource outcome. The earlier RFC 10027 Article retains the attacker-controlled cross-device request-context thesis; this Article examines the honest-flow reconstruction receipt defined by revision 00.