Mon plan d'actualisation JWT est-il sécurisé?
Je prévois d'utiliser JWT pour mon système de connexion pour les appareils mobiles. Il n'y a pas de véritable flux de travail standard pour rafraîchir les jetons JWT que j'ai pu trouver, j'ai donc créé celui-ci ci-dessous. La raison pour laquelle je souhaite utiliser JWT est pour des raisons de performances. Au lieu de vérifier si un utilisateur est valide avec un appel de base de données pour chaque demande, je fais confiance au JWT.
J'ai le workflow proposé que je souhaite implémenter dans mon application. Cette sécurité est-elle acceptable? Efficace? Y a-t-il des problèmes évidents que je supervise? Quelles améliorations raisonnables peuvent être apportées?
L'utilisateur se connecte
- Si aucun jeton signé HMAC n'existe dans le stockage local, l'utilisateur donne un nom au périphérique.
- DeviceName est envoyé au serveur où il est inséré dans la base de données.
- Le jeton JWT + le jeton signé HMAC de DeviceName sont renvoyés à l'utilisateur. Le jeton signé HMAC est mis en place pour s'assurer que le jeton jwt (contenant DeviceName) est envoyé à partir du même périphérique qui l'a appelé à l'origine.
- Le jeton JWT est valide pendant X heures afin qu'un utilisateur puisse effectuer des appels pendant X heures.
- Après X heures, le JWT est expiré. Lorsqu'une demande est faite, le serveur peut voir que le JWT a expiré. Le serveur va maintenant tenter de rafraîchir le jeton JWT. Le serveur vérifie la base de données pour voir si le nom de périphérique spécifié dans le jeton signé HMAC est le même qu'un nom de périphérique valide dans la base de données pour cet utilisateur.
- Si tel est le cas, créez un nouveau JWT valable pendant encore X heures, sinon, renvoyez un message pour demander une connexion.
Si un compte est compromis:
L'utilisateur peut se connecter à mon service de mot de passe. Une fois connecté, je récupérerais tous les appareils de cet utilisateur, l'utilisateur peut alors révoquer son appareil compromis. Une fois cela fait, une demande d'actualisation du JWT ne fonctionnera pas avec le jeton volé.
Tout cela se produit bien sûr via SSL.
Mes préoccupations pour lesquelles je n'ai pas de solution:
Si un jeton JWT est volé, l'attaquant dispose de X heures pour effectuer des appels en fonction de la victime. Je pense que c'est la nature des jetons et un risque accepté?
Si le JWT est volé, cela signifie qu'il y a de fortes chances que le jeton HMAC contenant le nom de l'appareil soit également détourné afin que l'utilisateur puisse actualiser les jetons jusqu'à ce que la victime se rende compte que son compte est compromis et révoque l'accès. Est-ce une pratique acceptée?
Sécuritaire acceptable dans le domaine de quoi?
Vous avez décrit le flux de base pour tous les jetons de porteur. Ceux qui portent le jeton ont le pouvoir. Vous avez une condition dans laquelle vous vérifiez si le jeton a été révoqué, mais cela signifie que le jeton est valide jusqu'à leur expiration ou leur révocation. C'est fondamentalement la même chose que de vérifier si l'utilisateur est valide dans la base de données, mais vous remplacez l'utilisateur par device + JWT. C'est bien, mais ce n'est pas vraiment un gain de performances.
D'autres systèmes utilisent deux JWT (ou un JWT et un jeton opaque). Le premier JWT est votre jeton d'accès utilisé principalement comme vous le décrivez, mais vous ne vérifiez pas la révocation. Ce jeton est de très courte durée - peut-être 20 min -> 1h, puis vous avez votre jeton d'actualisation qui vit considérablement plus longtemps. Lorsque votre jeton d'accès expire, vous envoyez le jeton d'actualisation et si le jeton d'actualisation est toujours valide, vous émettez un nouveau jeton d'accès. Si le jeton d'actualisation a expiré, vous pouvez à nouveau forcer l'authentification ou simplement émettre un nouveau jeton d'accès et d'actualisation.
La valeur ici est que vous n'avez qu'à valider le jeton d'actualisation par rapport à la base de données, et vous ne devez le faire qu'à l'expiration du jeton d'accès. Lorsque l'utilisateur marque le jeton d'actualisation comme révoqué, le jeton d'actualisation n'obtient pas à l'attaquant un nouveau jeton d'accès.
Le compromis est que vous n'interrogez pas dans la base de données aussi souvent, mais l'attaquant peut faire ce qu'il veut tant que le jeton d'accès est valide. Ceci est atténué par l'utilisation d'un jeton de très courte durée (c'est un jeu de cotes). Que ce soit un risque accepté dépend entièrement de vous. Nous ne dictons pas si vous devez accepter le risque. :)