Resumen

  • RFC 10027 explica ataques en los que el adversario inicia el protocolo legítimo y convence a la víctima de introducir o aprobar el código auténtico. La autorización se emite al dispositivo que controlaba el adversario.
  • El expediente probatorio debe unir iniciador, cliente, dispositivo de consumo, recurso, alcance, acción y consecuencia antes de la aprobación, y seguir el token hasta el último servidor y la última sesión durante la recuperación.

Un atacante abre una aplicación de consola y solicita acceso. El servidor devuelve un código de dispositivo y una dirección de verificación. En vez de completar el proceso, el atacante llama a una administradora y afirma que ese código pertenece al monitor de una sucursal. Ella abre la dirección oficial en el móvil corporativo, usa una credencial WebAuthn y aprueba. El token llega a la consola del atacante porque esa consola fue la que inició la operación.

La autenticación no falló. La historia que conectaba ambos dispositivos era falsa.

RFC 10027, publicado en agosto de 2026 como BCP 247, distingue autorización entre dispositivos y transferencia de sesión. Describe ataques entre protocolos y dentro del mismo protocolo contra el canal de contexto no autenticado que une el dispositivo de consumo con el dispositivo de autorización.

Un código transfiere una referencia, no una intención

RFC 8628 permite que un dispositivo con entrada limitada obtenga un código, muestre al usuario dónde verificar y consulte el resultado hasta recibir tokens. El diseño resuelve una limitación de interfaz; no prueba quién trasladó el código ni por qué.

Acortar la vigencia, impedir la reutilización y dar unicidad reduce el margen de adivinación o repetición. Un adversario en directo puede generar el código después de preparar a la víctima y consumir la aprobación inmediatamente. Por eso “código de un solo uso” y “solicitud iniciada por la persona” son afirmaciones distintas.

OAuth 2.0 distribuye funciones entre cliente, propietario, servidor de autorización y servidor de recursos. PKCE demuestra que el cliente que canjea un código posee el verificador original. Si ese cliente pertenece al atacante, PKCE conserva con rigor el vínculo técnico que la víctima interpretó mal.

La identidad no contiene el significado de la transacción

WebAuthn nivel 3 puede ofrecer autenticación vinculada al origen y resistente al phishing. Eso dificulta el robo de credenciales, pero no muestra automáticamente el dispositivo solicitante, el recurso final, el alcance o una transferencia irreversible. El usuario puede estar en el origen correcto y razonar sobre la operación equivocada.

RFC 10027 recomienda usar el flujo de dispositivo de RFC 8628 solo cuando las restricciones impidan alternativas superiores y evitarlo para recursos sensibles, valiosos o críticos. Los dispositivos prerregistrados y “autenticar antes de iniciar” bloquean solicitudes arbitrarias cuando el producto puede exigirlos.

La proximidad sirve como fricción, no como identidad. Redes móviles, Wi-Fi, VPN y suplantación hacen que distancia física y topología diverjan, y una medición precisa consume privacidad. La verificación fuera de banda también puede reenviarse. Hay que conservar qué dato se comparó, con qué precisión, quién lo presentó y a qué identificador de solicitud quedó unido.

Restringir el token no corrige a quién se autorizó

DPoP liga el token a una clave del cliente y reduce la utilidad de una copia robada. Pero el atacante que controla el dispositivo autorizado también controla la clave: la restricción protege el ejercicio de un consentimiento obtenido para el contexto equivocado. RFC 9700 mejora la seguridad general de OAuth, sin convertir una firma en prueba de intención humana.

OpenID CIBA evita trasladar un código visible y por ello reduce este patrón. No elimina solicitudes masivas, cansancio ante avisos o engaños de falso soporte cuando el solicitante conoce un identificador de usuario.

La recuperación abarca más sistemas que la emisión. Introspección, revocación y eventos CAEP ayudan a propagar decisiones. El estado “revocado” en el servidor de autorización no prueba que un servidor de recursos dejó de aceptar caché, que una sesión derivada terminó o que un token de actualización no produjo descendientes.

Registrar el contexto que el usuario pudo juzgar

El registro debe capturar ID y hora de inicio, iniciador, client ID y versión, identidad y confianza del dispositivo de consumo, dispositivo de autorización y método de autenticación, hash y vida del código, canal de transferencia, señales de proximidad y la presentación exacta de solicitante, equipo, recurso, alcance, acción, destino y efecto irreversible.

Después se añade la familia de tokens, clave de confirmación, usos por servidor, alertas, rechazos, tiempos de introspección y revocación, entrega y confirmación CAEP y prueba positiva de terminación. No se debe condensar en un único “riesgo bajo”.

La primacía del código en ejecución de Heng Lu sitúa la verdad operacional en el cliente y el recurso que ejercen el acceso. Su especificación inicial mínima con decisiones locales permite fijar un contrato común de evidencia sin imponer la misma arquitectura a cada dispositivo. Su análisis del control formal y práctico de los datos aclara el desenlace: el servidor formaliza la autorización; quien dispone de la clave y la sesión conserva el control práctico.

Una MFA correcta responde quién estaba ante el móvil. No responde quién estaba detrás de la solicitud.