Quelle est la différence entre JWT et le chiffrement manuel de json avec AES?
Quelle est la différence entre l'utilisation d'un jeton Web JSON (JWT) et le simple fait d'avoir une clé AES et d'envoyer et de recevoir du JSON chiffré du client?
Par exemple, cela pourrait être envoyé au client:
AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
Les jetons Web JSON (= JWT) sont basés sur RFC 7519 et toutes les différences y seront décrites en détail. Si vous regardez cela, vous verrez qu'ils sont bien plus que ce que vous semblez avoir à l'esprit.
Entre autres choses, ces jetons:
- sont utilisés pour faire valoir des revendications (par exemple, "connecté en tant qu'administrateur")
- sont signés avec un code d'authentification de message (par exemple HMAC-SHA256) (l'algorithme est spécifié dans l'en-tête du JWT)
- avoir une charge utile contenant la ou les réclamations (équipée d'un horodatage)
La signature est encodée en base64url. Ceci est décrit dans section 3.1 et Appendice A.1 du RFC.
Vous pouvez faire tout cela avec une implémentation élaborée du partage des revendications, mais pourquoi le feriez-vous?
Il existe des normes, des normes et des RFC pour une raison. Ils ont été testés par des experts, ils sont fiables et les gens les utilisent pour une raison. C'est une bonne chose que (presque) tout le monde pèse ses fruits en kilos et parcourt sa distance en kilomètres. Les systèmes standardisés facilitent le partage d'informations et sont facilement utilisables par de nombreuses personnes.
La conclusion de votre argumentation derrière ceci: Ne construisez pas de solutions trop compliquées pour des problèmes qui ont des solutions testées et fiables .
Aussi: jetez un oeil à ceci pour un autre "Quelle est la différence ..?" question: Quelle est la différence entre SHA et le cryptage AES?
De mon autre sec.SE réponse :
Les JWT sont des jetons autonomes qui sont utilisés pour partager des informations d'authentification entre différents systèmes. Ils résolvent le problème du recours à des tiers pour valider un jeton d'authentification, car toutes les informations requises pour valider le JWT sont contenues dans le jeton lui-même. Cela simplifie le processus d'intégration dans un système d'authentification unique car l'intégration est minimale. Les JWT sont également compatibles avec HTTP car ce ne sont que des chaînes BASE-64.
Vous n'avez pas fourni suffisamment d'informations sur l'architecture de votre application. Dans votre cas particulier, il serait difficile pour un autre tiers ou un serveur de ressources de confiance de valider le jeton AES que vous avez émis. La seule façon de le faire serait de partager votre clé de chiffrement AES avec tous ceux qui souhaitent vérifier le jeton d'authentification émis par vous. Ce serait une mauvaise décision de conception qui peut avoir de graves problèmes de confidentialité et d'intégrité.
De plus, les jetons doivent prendre en charge des fonctionnalités de sécurité importantes telles que des horodatages qui permettent à une ressource d'empêcher les attaques de rejeu de jetons. Votre conception ne prend pas en charge cela.
AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
Votre jeton de sécurité pour l'utilisateur administrateur avec un identifiant unique 5552 aura toujours la même valeur. En bref, vous ne devriez pas essayer de réinventer la roue et vous fier aux méthodes et cadres existants pour l'authentification. Les JWT ont eu leur part de sécurité issues dans le passé. lire plus .
Différences:
- JWT envoie le texte en clair et le hmac de celui-ci, mais vous envoyez à la place le message crypté
- Les JWT sont un standard et ont des bibliothèques en plusieurs langues
Le problème avec votre système est que le client ne peut pas lire le contenu du jeton (par exemple, quel utilisateur est le propriétaire).