La especificación de OpenID Connect requiere clientes de flujo implícito para generar y validar un nonce:
Valor de cadena utilizado para asociar una sesión del Cliente con un token de ID y para mitigar los ataques de reproducción.
¿Qué ataques de repetición son esos?
Dicho de otra manera, ¿cuál es el impacto en la seguridad de no validar el nonce cuando se usa el flujo implícito?
Dar una idea descabellada de paquetes de reproducción y uso de nonces. Esto no trata con OpenId es mi idea general.
Supongamos en la comunicación de dos partes A y B; A está compartiendo su clave a B para probar su identidad, pero mientras tanto, Atacante C Escuche la conversación entre ellos y guarde la información necesaria para demostrar su identidad a B.
Posteriormente, C contacta a B y demuestra su autenticidad.
Ejemplo: si A tiene un caché nonce que almacena un número de nonce pseudoaleatorio. Lo usa directamente para hacer el paquete de respuesta. A que borra la memoria caché cuando recibe el primer paquete de respuesta de B.
Para la próxima transmisión, nuevamente se guarda un nonce aleatorio nuevo en el caché nonce de A. Y se utiliza para transmitir paquetes a B.
Si C después de algunas veces intenta reproducir un paquete a A. A se descartará debido a un error incorrecto.
Nota: Los nonces se pueden cifrar y enviar. Puede haber varias formas de usar nonces de acuerdo con el protocolo.
Mi comprensión actual es la siguiente:
El cliente (una aplicación web que se ejecuta en el navegador del usuario) genera un nonce, lo coloca en el almacenamiento de la sesión del navegador y lo redirige al servidor de autenticación, pasando el nonce como parámetro. Después de la autenticación, el servidor de autenticación redirige al cliente, pasando un token de identificación firmado que contiene el nonce, que el cliente debe validar con el nonce desde el almacenamiento de la sesión.
Si el nonce no está validado, un atacante podría sustituirlo por otro identificador de identificación, engañando al usuario para que visite su sitio y enviando un redireccionamiento con un identificador de identificación válido obtenido de una solicitud diferente.
Además del identificador de identificación, el servidor de autenticación también responde con un identificador de acceso. Si el nonce no está validado, un atacante podría sustituir un token de acceso diferente, engañando al usuario en su sitio y redirigiéndolo con ese token. Esto podría usarse para un ataque de denegación de servicio del lado del cliente (en particular si las pestañas del navegador comparten el almacenamiento de token, es decir, usan el almacenamiento local en lugar del almacenamiento de sesión).
En resumen, la validación de nonce es necesaria para confiar en el token de identificación. Si el token de identificación no necesita ser confiable, se puede omitir la validación de nonce.
Lea otras preguntas en las etiquetas authentication openid-connect nonce