La spécification JWT mentionne une revendication jti qui pourrait prétendument être utilisée comme une simple exception pour empêcher les attaques par rejeu:
La revendication jti (ID JWT) fournit un identifiant unique pour le JWT. La valeur de l'identificateur DOIT être affectée de manière à garantir qu'il existe une probabilité négligeable d'attribution accidentelle de la même valeur à un objet de données différent. si l'application utilise plusieurs émetteurs, les collisions DOIVENT également être évitées entre les valeurs produites par différents émetteurs. La revendication jti peut être utilisée pour empêcher la lecture du JWT. La valeur jti est une chaîne sensible à la casse. L'utilisation de cette revendication est FACULTATIVE.
Ma question est la suivante: comment procéder pour mettre cela en œuvre? Dois-je stocker les jtis précédemment utilisés et émettre un nouveau JWT à chaque demande? Si tel est le cas, cela ne va-t-il pas à l'encontre de l'objectif des JWT? Pourquoi utiliser un JWT au lieu de simplement stocker un identifiant de session généré de manière aléatoire dans une base de données?
Mon API REST a une base de données Mongo et je ne suis pas opposée à l'ajout d'une instance Redis. Existe-t-il une meilleure option d'authentification que JWT? Je ne veux surtout pas stocker de mots de passe sur le client. ce qui élimine l'authentification HTTP en tant qu'option, cependant, au fur et à mesure que j'approfondis ce sujet JWT, je commence à avoir l'impression qu'une implémentation de jeton personnalisé ou un autre standard pourrait mieux répondre à mes besoins. authentification basée qui prend en charge la révocation de jeton et la rotation de jetons?
J'apprécierais tout conseil.
En effet, le stockage de tous les ID JWT émis sape la nature sans état de l’utilisation des JWT. Cependant, les ID JWT ont pour objectif de pouvoir révoquer les JWT précédemment émis. Pour ce faire, il est très facile d’obtenir une liste noire au lieu d’une liste blanche. Si vous avez inclus la réclamation "exp" (vous devriez le faire), vous pourrez éventuellement nettoyer les JWT inscrits sur une liste noire à mesure qu'ils expirent naturellement. Bien sûr, vous pouvez également implémenter d’autres options de révocation (par exemple, révoquer tous les jetons d’un client sur la base de la combinaison de "iat" et "aud").
Voir express-jwt sur GitHub ou sur NPM .
Express-jwt traite les jetons révoqués comme décrit ici: https://github.com/auth0/express-jwt#revoked-tokens
var jwt = require('express-jwt');
var data = require('./data');
var utilities = require('./utilities');
var isRevokedCallback = function(req, payload, done){
var issuer = payload.iss;
var tokenId = payload.jti;
data.getRevokedToken(issuer, tokenId, function(err, token){
if (err) { return done(err); }
return done(null, !!token);
});
};
app.get('/protected',
jwt({secret: shhhhhhared-secret,
isRevoked: isRevokedCallback}),
function(req, res) {
if (!req.user.admin) return res.send(401);
res.send(200);
});
Vous pouvez également lire la partie 4. Comment éviter d’ajouter des frais généraux? à partir de cet article de blog oauth .