Summary

  • draft-richer-oauth-oob-authcode-00 permite que un cliente sin callback accesible reciba una sola cadena copiada que encapsula el código de autorización mediante el state guardado; es una propuesta individual, no un documento adoptado ni una RFC.
  • La helper page deriva un flujo con HKDF, aplica XOR al código y añade un checksum de tres bytes. El cliente invierte la operación y todavía debe canjear el código en el token endpoint.
  • Que la reconstrucción sea coherente no demuestra confidencialidad, emisor, PKCE, aceptación del canje, permiso sobre la API ni efecto de negocio.

El navegador llega donde el cliente no puede

Una herramienta de línea de comandos puede lanzar el navegador del usuario y, aun así, no disponer de una URL local alcanzable para recibir el retorno. La revisión 00 conserva el authorization code grant: registra una página auxiliar estática, deja que el authorization server redirija allí con code y state, y usa al usuario como tramo final hasta el cliente que espera.

La página no tiene estado de backend ni secreto previo con el cliente. No modifica al authorization server y no pide el access token. Solo entrega una representación que pretende reducir la confusión entre dos cadenas distintas.

Ese reparto es importante. El servidor puede haber emitido un código; la página puede haber mostrado una cadena; el usuario puede haberla pegado. Ninguno de esos hechos dice todavía que el cliente obtuvo un token utilizable.

La prueba corta de una reconstrucción

El helper convierte el código en C. De state, sal vacía y un INFO compartido, HKDF genera KS con igual longitud. E = C XOR KS. Los primeros tres bytes de SHA256(C) forman T. La concatenación de T y E, codificados por separado en base64url sin padding, produce CC.

El cliente conserva el state original, vuelve a obtener KS, recupera el código y compara el checksum. Si no coincide, falla; si la entrada no supera los cuatro caracteres que representan los tres bytes de control, debe descartarla. Después usa el código reconstruido en la solicitud de token.

Tres bytes sirven para detectar errores dentro de este formato. No son una firma del authorization server. Cualquier persona puede alimentar la página estática con valores arbitrarios. Una coincidencia no identifica al creador, al navegador, al emisor ni al usuario, y tampoco convierte el código en vigente o de un solo uso.

La página ve los valores antes de ocultarlos

El GET que carga el helper incluye code y state. El origen, sus CDN, réplicas y cachés pueden recibirlos. El XOR ocurre después de esa transferencia. La especificación reconoce que no hay confidencialidad nueva y que el cliente no queda protegido si ambos valores son robados.

El state deja de ser un accesorio pasajero: el cliente debe guardarlo hasta la devolución, hacerlo suficientemente aleatorio para HKDF y, como mínimo, único por solicitud. Un cliente sin estado que esperaba reconstruir todo a partir del callback no puede aplicar este método.

Si JavaScript no funciona, el fallback recomendado copia la URL completa. Entonces el cliente extrae code y state directamente y no existe CC. El flujo también descarta parámetros adicionales, incluido iss; solo podría incorporarlo a INFO si el perfil supiera que el servidor lo devuelve. La ruta de issuer validation debe seguir visible.

Después del pegado empieza otra verificación

RFC 6749 todavía gobierna el enlace del código, la redirección y el canje. PKCE, cuando se usa, obliga a presentar el verifier relacionado con el challenge. La autenticación del cliente, la expiración, el uso único y las defensas de RFC 9700 no se deducen del checksum.

RFC 8628 ofrece el device authorization grant, con participación del servidor y polling. El nuevo borrador quiere evitar ese grant adicional y varias rondas. Esa ventaja operativa no es un veredicto sobre qué flujo resiste mejor cada amenaza ni cuál ofrece mejores recibos de recuperación.

La Minimum Initial Specification de Lu Heng evita inflar la capa común: CC debe ser un mecanismo de transferencia menos propenso a errores. Running-Code Primacy empieza después, con lo que el cliente recuperó, lo que el token endpoint aceptó y lo que el resource server ejecutó. Una interfaz con una sola cadena no crea una sola realidad.

Fuentes y límites

Estas fuentes no prueban adopción por OAuth, consenso IETF, RFC, implementación, interoperabilidad, despliegue, login completado, token emitido, ataque, eficacia de una mitigación ni resultado de una API. El Artículo anterior sobre RFC 10027 conserva el ataque de contexto entre dispositivos; este texto se limita al recibo de reconstrucción del flujo honesto de la revisión 00.