Learn-json-web-tokens: ¿Por qué el "uso único" podría resolver MITM?

@ NE-SmallTown buena pregunta.
El uso de tokens de un solo uso es una buena práctica para la seguridad de las aplicaciones.
Si desea utilizar este patrón, puede configurar un gancho onPreResponse que actualice automáticamente el JWT para cada respuesta.

la pregunta que debe responder es: ¿cómo planea asegurarse de que un token _no_ se reutilice?
necesitaría almacenar el identificador en algún tipo de base de datos (_ normalmente usamos redis para esto en nuestras aplicaciones_) y verificar si el token ya se ha utilizado.

@nelsonic Gracias por tu respuesta Estoy un poco confundido.

Hay una pregunta.

Como dices, el proceso es:

el usuario accede a la página de inicio y envía el token en el encabezado (suponiendo que haya iniciado sesión)

                                       |
                                       |
                                       ↓

el servidor recibe el token y luego obtiene el userId decodificando el token, y luego va a la base de datos (asumiendo que uso la base de datos en lugar de redis ) para tomar el token correspondiente de userId , y luego verifique si son iguales usando el operador == . Si lo es, luego destruya el token y genere un nuevo token y envíelo a la base de datos y responda con los datos al cliente.

Hay una pregunta, solo usamos el operador == para verificar, pero sabemos que el token en sí tiene el mecanismo de vertificar, ¿no lo usamos ?

JWT.require(Algorithm.RSA256((RSAKey) publicKey))
                .withIssuer("auth")
                .withSubject("ne-smalltown")
                .withAudience(userId)
                .withArrayClaim("jwt-role", userRole)
                .build()

Si me equivoco, ¿podría decirme cómo y dónde usar el mecanismo de vertificación del token como el anterior?

En mi opinión, el único lugar en el que puedo usar el mecanismo de vertificación del token es donde obtengo el parámetro exp del token antiguo y lo pongo en el token nuevo para poder verificar si el token está desactualizado para que el usuario vuelva a iniciar sesión.

                                        |
                                        |
                                        ↓

El cliente recibe el nuevo token y lo empuja al localstorage para reemplazar el token anterior, y en la siguiente solicitud, lo usará.

@nelsonic ¿Hola?

@ NE-SmallTown mis disculpas por no responder de inmediato.
La especificación JWT no tiene un reclamo / mecanismo para la invalidación de un solo uso
ver: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName

@jbspeakr tiene una publicación sobre cómo usar JWT de un solo uso,
ver: https://www.jbspeakr.cc/howto-single-use-jwt/

@nelsonic Gracias por compartir la publicación.

La publicación dice:

En teoría, esto también funciona con casos de uso además de tokens de restablecimiento de contraseña, por ejemplo, activación por correo electrónico, confirmación de cuenta

Estoy de acuerdo en que estos casos son adecuados para jwt de uso único, pero mi caso es que el jwt incluye la información del rol constante , no le gusta el restablecimiento de contraseña, la activación por correo electrónico, la confirmación de la cuenta, etc.

Entonces, volviendo a la pregunta, en mi caso, ahora creo que no es necesario vertificar el token, solo use el operador == con el token de la base de datos.