Quel devrait être le "secret" dans JWT?
Je vais appliquer JWT dans mon REST développée en utilisant Java-Jersey. J'utilise cette bibliothèque pour JWT - https://github.com/auth0/Java-jwt
J'ai quelques questions sur le JWT - Secret
- Ce
Secretdoit-il être unique? - Dois-je utiliser la version hachée du mot de passe de l'utilisateur pour le secret? (Alors ce n'est pas unique de toute façon) C'est parce qu'alors, lorsque l'utilisateur a changé son mot de passe, son jeton sera automatiquement invalide.
- Ce
Secretdoit-il être unique?
Il doit être unique pour votre application - il doit être un secret, après tout - mais il ne sera pas unique pour chaque jeton. Au lieu de cela, vous devriez avoir un nombre relativement petit de clés secrètes à un moment donné (par exemple, avoir généralement une seule clé, mais avoir de brèves périodes où vous avez deux clés lorsque vous tournez d'une clé à l'autre).
- Dois-je utiliser la version hachée du mot de passe de l'utilisateur pour le secret?
Non, pour deux raisons:
- Supposons que votre utilisateur dispose d'un mot de passe relativement non sécurisé, comme
GoPackers123. L'utilisation du mot de passe dans votre secret signifie alors que quelqu'un peut facilement tester un mot de passe potentiel donné pour voir s'il donne la bonne signature; et, plus précisément, ils peuvent facilement tester un grand nombre de mots de passe potentiels pour voir si l'un d'eux donne la bonne signature. Il s'agit d'une attaque hors ligne, vous ne sauriez même jamais que cela s'est produit. - Cela vous obligerait à distribuer tous les hachages de mot de passe de vos utilisateurs à chaque système qui doit garder le secret. Si vous avez plus qu'un nombre insignifiant d'utilisateurs, cela peut devenir un fardeau assez sérieux pour votre mécanisme de distribution de secrets.
JWT et la bibliothèque Java-jwt prennent en charge symétrique et asymétrique algorithmes pour la signature:
Si vous optez pour des algorithmes symétriques tels que HS256, vous n'aurez qu'une seule clé à utiliser pour signer et vérifier la signature.
Si vous considérez des algorithmes asymétriques tels que RS256, vous aurez une clé privée et une clé publique. Conservez la clé privée en sécurité sur le serveur et utilisez-la pour signer le jeton. Utilisez la clé publique pour vérifier la signature (elle peut également être partagée avec quiconque a besoin de vérifier la signature).
Jamais jamais partagez la clé utilisée pour signer le token!
Et rien ne vous empêche d'avoir un ensemble de clés différentes pour signer vos jetons. Dans cette situation, le paramètre d'en-tête kid peut être utilisé pour indiquer quelle clé a été utilisée pour signer le jeton. Cette revendication est censée porter un identifiant de clé et non la clé elle-même.
Reportez-vous à cette réponse pour plus de détails sur la revendication kid .
Utilisez RSA256, c'est-à-dire une paire de clés privée/publique (aucun `` secret '' requis). De cette façon, vous pouvez garder la clé privée secrète et sûre (elle ne sera utilisée que pour signer le jeton) et vous pouvez utiliser la clé publique pour vérifier que la signature est correcte.
Vous pouvez donner la clé publique à toute personne ou tout service qui doit vérifier que la signature du jeton est correcte.