Resumen

  • Justin Richer presentó el 28 de septiembre un Internet-Draft individual que permite devolver a un cliente remoto un código OAuth mediante un único valor copiable.
  • El formato no añade seguridad al flujo de código: el sitio auxiliar recibe code y state, mientras el cliente conserva la tarea de verificar la solicitud y el servidor previstos.

Una terminal en una máquina remota puede iniciar la autorización, pero quizá no pueda ofrecer una URL de retorno a la que llegue el navegador de la persona. Ahí aparece el problema que aborda draft-richer-oauth-oob-authcode-00. El servidor redirige a una página auxiliar previamente registrada y la persona copia de esa página un valor hacia el cliente que espera. Es una propuesta individual publicada el 28 de septiembre de 2026 con intención informativa; Datatracker indica I-D Exists. No es un RFC ni una decisión de un grupo de trabajo.

El mecanismo evita pedir al servidor de autorización una concesión nueva. La página toma los parámetros code y state de la respuesta habitual, combina datos mediante HKDF, XOR y una suma de comprobación, y presenta un solo texto para copiar. La terminal retuvo su state original; con él reconstruye el código y continúa en el extremo de tokens ordinario. El cambio visible para el usuario es pequeño, pero exige registrar la dirección de la página como redirección autorizada.

El nombre del algoritmo no debe distraer de la ruta del dato. El borrador aclara que la combinación no es más segura que el flujo básico de código de autorización. El código pasó por el navegador y llegó en la URL de una solicitud GET al sitio auxiliar. Que este sea una página estática sin estado no impide que el servidor, una CDN, una réplica o sus registros vean code y state. Tampoco convierte la cadena de distribución de la página en un canal de confianza por defecto.

La cadena copiable no demuestra por sí sola qué servidor emitió el código. La transformación es reproducible con valores escogidos libremente. Por eso importa lo que la terminal ya sabe: qué petición sigue abierta, cuál era el state conservado y a qué extremo de tokens piensa acudir. Un cliente incapaz de retener estado no puede seguir la vía propuesta. Si falla JavaScript, el texto contempla copiar la URL entera; ese recurso entrega los parámetros originales y no equivale al formato combinado.

Hay además una pérdida de contexto potencial que debe describirse con cuidado. El valor propuesto transporta code y state, no todos los parámetros de la respuesta; iss no viaja como campo independiente. La sección 3.4 plantea utilizarlo en INFO de HKDF si el cliente sabe que el servidor lo incluye. RFC 9207 ya establece una señal de emisor para mitigar la confusión entre servidores de autorización en clientes que usan varios. La omisión no prueba una vulnerabilidad universal. Sí obliga a esos clientes a explicar cómo mantienen su propia vinculación con el emisor durante el traspaso manual.

RFC 8628 ofrece otro camino para dispositivos, con cooperación del servidor y sondeos. Esta propuesta no lo deroga ni demuestra que sea inferior. Su atractivo es reutilizar un flujo conocido cuando el cliente vive lejos del navegador. La decisión de ingeniería cambia de lugar: menos extensión en el servidor, más atención a la procedencia de la página auxiliar y al acto humano de copiar.

Fuentes