Learn-json-web-tokens: Pourquoi le « usage unique » pourrait-il résoudre le MITM ?

@NE-SmallTown bonne question.
L'utilisation de jetons à usage unique est une bonne pratique pour la sécurité des applications.
Si vous souhaitez utiliser ce modèle, vous pouvez configurer un crochet onPreResponse qui met automatiquement à jour le JWT pour chaque réponse.

la question à laquelle vous devez répondre est : comment comptez-vous vous assurer qu'un token n'est _pas_ réutilisé ?
vous devrez stocker l'identifiant dans une sorte de base de données (_nous utilisons généralement redis pour cela dans nos applications_) et vérifier si le jeton a déjà été utilisé.

@nelsonic Merci pour votre réponse.Je suis un peu confus.

Il y a une question.

Comme tu dis, le processus est :

l'utilisateur accède à la page d'accueil et envoie le jeton dans l'en-tête (en supposant qu'il se soit connecté)

                                       |
                                       |
                                       ↓

le serveur reçoit le jeton, puis récupère le userId en décodant le jeton, puis va à la base de données (en supposant que j'utilise la base de données plutôt que redis ) pour prendre le jeton correspondant du userId , puis vérifiez s'ils sont égaux en utilisant l'opérateur == Si c'est le cas, détruisez le jeton et générez un nouveau jeton, puis envoyez-le dans la base de données et répondez-le ainsi que les données au client.

Il y a une question, nous utilisons juste l'opérateur == pour vérifier, mais nous savons que le jeton lui-même a le mécanisme vertify, nous ne l'utilisons pas ?par exemple :

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

Si je me trompe, pourriez-vous me dire comment et où utiliser le mécanisme de vertify du jeton comme ci-dessus ?

OMI, le seul endroit où je peux utiliser le mécanisme de vertify du jeton lui-même est l'endroit où je récupère le paramètre exp de l'ancien jeton et le met dans le nouveau jeton afin que je puisse vérifier si le jeton est obsolète pour que l'utilisateur se reconnecte.

                                        |
                                        |
                                        ↓

Le client reçoit le nouveau jeton et le pousse vers le localstorage pour remplacer l'ancien jeton. Et lors de la prochaine requête, il l'utilisera.

@nelsonic Bonjour ?

@NE-SmallTown, je m'excuse de ne pas avoir répondu immédiatement.
La spécification JWT n'a pas de revendication/mécanisme d'invalidation à usage unique
voir : http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName

@jbspeakr a un article sur la façon d'utiliser des JWT à usage unique,
voir : https://www.jbspeakr.cc/howto-single-use-jwt/

@nelsonic Merci d'avoir partagé la publication.

Le poste dit :

En théorie, cela fonctionne également avec des cas d'utilisation en plus des jetons de réinitialisation de mot de passe, par exemple l'activation par e-mail, la confirmation de compte

Je suis d'accord que ces cas conviennent à un jwt à usage unique, mais mon cas est que le jwt inclut les informations sur le rôle de constant , il n'aime pas la réinitialisation du mot de passe, l'activation par e-mail, la confirmation du compte, etc.

Donc, revenons à la question, dans mon cas, maintenant je pense qu'il n'est pas nécessaire de vertifier le jeton, utilisez simplement l'opérateur == avec le jeton de la base de données.