Comment puis-je invalider le jeton JWT lorsqu'un utilisateur clique sur le bouton de déconnexion? J'ai fait quelques recherches mais je n'ai pas pu trouver de bonne implémentation. Je demande gentiment votre aide.
3 Réponses :
Vous n’avez trouvé aucun moyen d ’« expirer »le JWT car il n’existe pas de tel moyen. Nous pouvons dire que c'est un inconvénient de JWT .
Si le token est compromis, c'est un énorme problème. Vous voudrez peut-être envisager un autre mécanisme d'authentification si vous devez invalider des jetons / sessions.
La seule façon d '"invalider" un tel jeton serait d'utiliser une autre clé secrète sur le backend - ce qui est évidemment une idée exceptionnellement horrible!
Cependant, si vous cherchez un moyen de "déconnecter" l'utilisateur sur le frontend, effacez simplement le JWT du stockage. (Pourtant, si cet utilisateur a copié le jeton, il sera en mesure d'exécuter des requêtes contre l'api rest).
Pouvez-vous suggérer un bon mécanisme d'authentification à implémenter avec l'api de repos de démarrage à ressort qui permettra d'invalider et d'actualiser les propriétés du jeton.
C'est un sujet très large et nécessite une discussion / considération par rapport aux exigences. Il existe de nombreux mécanismes et chacun d'eux a ses avantages et ses inconvénients. Sessions, authentification de base, OAuth, JWT et ainsi de suite. Vous auriez besoin de lire sur chacun d'eux et ensuite, après avoir rassemblé quelques connaissances, décidez.
Cette réponse est incorrecte. Il existe des moyens et ils sont vraiment simples, vérifiez ma réponse.
Une option est d'avoir simplement une table bannedUsers. Vous pouvez même mettre en cache cette table. Si un compte utilisateur est compromis, vous pouvez simplement les ajouter à la table jusqu'à ce que leur jeton expire. Ce serait une recherche à chaque fois (à moins d'être mis en cache), mais il y aurait probablement toujours 0 enregistrement sur la table, donc ce serait très rapide.
Sur la même ligne que @RonOhRob, je suggérerais le jti Revendication (JWT ID) . Cette revendication fournit un identifiant unique pour le JWT.
Votre charge utile JWT ressemblerait à:
JWTVerifier verifier = JWT.require(ALGORITHM).withIssuer(ISSUER).build();
DecodedJWT decoded = verifier.verify(jwt);
if (blacklistService.find(jwt.getId())) {
throw new JWTVerificationException();
}
User user = userService.loadByUsername(jwt.getClaim("username").asString());
if (user.getDenyBefore() != null && user.getDenyBefore().compareTo(jwt.getIssuedAt()) > 0) {
throw new JWTValidationException();
}
Lorsqu'un JWT expire manuellement, vous insérez le jti code> dans une liste noire. La valeur doit persister dans la table jusqu'à l'expiration naturelle du jeton. Maintenant, pour chaque requête, il faut également vérifier si jti à l'intérieur de la table; s'il est trouvé, l'accès est refusé.
Si un utilisateur veut expirer tous ses jetons, il existe une autre stratégie simple impliquant le iat (Issued At) claim: ajoutez un champ deny_before à user code> et enregistrez la date de l'appel d'API expire_all . Comme précédemment, vous devez ajouter une vérification à chaque demande.
Pour une référence complète sur la façon d'intégrer JWT dans Spring, jetez un œil à la vidéo de JavaBrain .
Le gars dans la vidéo utilise jjwt , mais je recommanderais le java d'auth0- jwt , qui à mon goût offre une meilleure interface:
JWT.create()
.withJWTId(UUID.randomUUID().toString())
.withIssuer(ISSUER)
.withIssuedAt(issueDate)
.withExpiresAt(expireDate)
.withClaim("username", user.getUsername())
.sign(Algorithm.HMAC256("secret"));
Maintenant, dans votre JWTFilter :
{
"iss": "example.com",
"iat": "1300819080",
"exp": "1300819380",
"jti": "123e4567-e89b-42d3-a456-556642440000",
"username": "mneri"
}
Eh bien, cela ne rend pas le jeton lui-même invalide. C'est une liste noire. C'est une chose différente. Bien sûr, cela peut être une solution dans certains cas, mais ce n'est pas une invalidation en soi.