Dans un article précédent, j'ai parlé des bases de JWT . Si sur vos doigts, c'est juste la clé avec laquelle nous ouvrons la porte à des ressources privées. Mais que se passe-t-il si cette clé est volée (plus précisément, ils feront un duplicata). Ensuite, quelqu'un d'autre pourra se connecter au serveur sous votre nom, et nous ne le saurons peut-être même pas. Nous ne voulons pas autoriser un tel scénario. Mais que faire?
Augmentez la sécurité
Je suggère aux lecteurs, avant de poursuivre de manière indépendante, de réfléchir à ce que nous pouvons faire avec la sécurité.
Voici quelques approches qui peuvent améliorer la sécurité. Vous pouvez écrire dans les commentaires quelles autres approches existent - je les ajouterai.
- Utilisation du protocole
https , qui protège le canal de données sur Internet. En fait, c'est un wrapper sur http , qui impose des protocoles cryptographiques supplémentaires - SSL et TLS - Ajout d'informations
IP à la payload . Ensuite, le jeton d'autres IP ne passera pas la vérification. Mais l' IP peut être truqué, et quoi faire avec IP adresses IP dynamiques ou lorsqu'un utilisateur se connecte à partir d'un téléphone dans un café ou un métro. Par conséquent, nous n'utiliserons pas cette approche. - Utilisez
RS256 . Cela garantit la sécurité de la clé privée elle-même. Mais avec les jetons, tout reste absolument tel qu'il était. Nous avons besoin de RS256 lorsque nous avons peur de transmettre la clé secrète à d'autres serveurs, ce qui peut ne pas être fiable. Nous ne leur donnons qu'un outil d'authentification par jeton, ce qui est absolument inutile pour un attaquant. - Utilisez des jetons de courte durée. Mais alors, l'utilisateur devra se reconnecter à chaque expiration. L'utilisateur s'ennuiera tôt ou tard et il quittera notre ressource.
- Mais que se passe-t-il si vous utilisez des jetons de courte durée de toute façon, mais que vous lui donnez un autre jeton, dont le but est uniquement d'obtenir un nouveau jeton de courte durée sans nouvelle autorisation? Un tel jeton est appelé jeton d'actualisation et il ne sera possible de l'utiliser qu'une seule fois. Ce sera mon article.
Rappelez-vous ce qu'est JWT
JWT tire parti des JWE codage JWS (Signature) et JWE (Encrypting). La signature ne permet pas à quelqu'un de truquer un jeton sans information sur la clé secrète, et l'encodage protège contre la lecture de données par des tiers.
Voyons comment ils peuvent nous aider à authentifier et autoriser l'utilisateur sur le site.
Authentification (authentification anglaise; du grec. Αὐθεντικός [authentikos] - réel, authentique; de αὐθέντης [authentes] - l'auteur) - procédure d'authentification. Dans notre cas, nous vérifions le login + mot de passe pour une correspondance avec l'entrée dans la base de données de données utilisateur.
Autorisation (autorisation en anglais - permission, autorisation) - accordant à l'utilisateur le droit d'effectuer certaines actions; et également le processus de vérification (confirmation) de ces droits lorsque vous essayez d'effectuer ces actions.
En d'autres termes, l'authentification vérifie la légalité de l'utilisateur, puis, si tout va bien, l'utilisateur devient autorisé, c'est-à-dire qu'il peut effectuer des actions autorisées avec la base de données. Habituellement, ces deux processus sont combinés, et il y a donc une confusion bien connue.
Types de jetons
- Les jetons d'accès (JWT) sont des jetons qui peuvent être utilisés pour accéder aux ressources protégées. Ils sont de courte durée , mais réutilisables . Ils peuvent contenir des informations supplémentaires, telles que la durée de vie ou
IP adresse IP d'où provient la demande. Tout dépend du désir du développeur. - Refresh Token (RT) - ces jetons n'effectuent qu'une seule tâche spécifique - l'obtention d'un nouveau jeton d'accès. Et cette fois, vous ne pouvez pas vous passer d'un serveur d'autorisation. Ils sont durables , mais jetables .
Le cas d'utilisation principal est le suivant: dès que l'ancien JWT expire, nous ne pouvons plus recevoir de données privées avec lui, puis nous envoyons RT et nous recevons une nouvelle paire de JWT+RT . Avec le nouveau JWT nous pouvons à nouveau nous tourner vers des ressources privées. Bien sûr, un jeton de rafraîchissement peut également mal tourner, mais cela ne se produira pas bientôt, car il vit beaucoup plus longtemps que son frère.
L'idée clé de la séparation des jetons est que, d'une part , les jetons d'autorisation nous permettent de vérifier facilement un utilisateur sans serveur d'autorisation, simplement en comparant les signatures.
const validateToken = token => { const [ header, payload, signature ] = token.split('.'); return signature === HS256(`${header}.${payload}`, SECRET_KEY); }
D'un autre côté , nous avons un
En conclusion
Grâce à cette approche, nous réduisons le délai d'accès au serveur de latency , et la logique du serveur elle-même devient beaucoup plus simple. Et d'un point de vue de la sécurité, si un jeton d'accès nous a été volé, seul un temps limité pourra l'utiliser - pas plus que sa durée de vie. Pour qu'un attaquant puisse utiliser plus longtemps, il devra également voler un rafraîchissement, mais le véritable utilisateur saura qu'il a été piraté car il sera expulsé du système. Et une fois qu'un tel utilisateur se connectera à nouveau, il recevra une paire mise à jour de JWT+RT , et ceux volés se transformeront en citrouille.
Liens utiles
- Pourquoi ai-je besoin d'un jeton d'actualisation si j'ai un jeton d'accès?
- Actualiser les jetons: quand les utiliser et comment ils interagissent avec les JWT
- Plus de surprises OAuth 2.0: le jeton d'actualisation