Qual è la differenza tra l'utilizzo di un JSON Web Token (JWT) e il semplice possesso di una chiave AES e l'invio e la ricezione di JSON crittografati dal client?
Ad esempio, questo potrebbe essere inviato al client:
AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
JSON Web Tokens (= JWTs) si basano su RFC 7519 e tutte le differenze verranno descritte in modo esauriente. Se dai un'occhiata a questo, vedrai che sono molto più di quello che sembra avere in mente.
Tra le altre cose, questi token:
La firma è codificata in base 64url. Questo è descritto in sezione 3.1 e Appendice A.1 della RFC.
Potresti fare tutto questo con un'elaborata implementazione in homegrown delle dichiarazioni di condivisione, ma perché dovresti? Ci sono standard, norme e RFC per una ragione. Sono stati testati da esperti, sono affidabili e le persone li usano per una ragione. È una buona cosa che (quasi) tutti pesano i loro frutti in chili e percorrono la loro distanza in chilometri. I sistemi standardizzati semplificano la condivisione delle informazioni e sono facilmente utilizzabili per molte persone.
La conclusione del tuo punto dietro questo: non costruire soluzioni eccessivamente complicate per problemi che hanno soluzioni provate e affidabili .
Inoltre: dai un'occhiata a questo per un altro "Qual è la differenza ..?" domanda: Qual è la differenza tra la crittografia SHA e AES?
Dalla mia altra sec.SE risposta :
JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-boarding in a single sign-on system as there is minimal integration required. JWT are also HTTP friendly as they are just BASE-64 strings.
Non hai fornito informazioni sufficienti sulla tua architettura dell'applicazione. Nel tuo caso particolare, sarebbe difficile per qualsiasi altra terza parte o un server di risorse attendibili convalidare il token AES emesso da te. L'unico modo per farlo sarebbe quello di condividere la chiave di crittografia AES con tutti coloro che desiderano verificare il token di autenticazione da te rilasciato. Questa sarebbe una cattiva decisione di progettazione che può avere gravi problemi di riservatezza e integrità.
Inoltre, i token devono supportare importanti funzionalità di sicurezza come timestamp che consentono a una risorsa di prevenire gli attacchi di riproduzione di token. Il tuo design non supporta questo.
AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)
Il tuo token di sicurezza per l'utente amministratore con un ID univoco 5552 avrà sempre lo stesso valore. In breve, non provare a reinventare la ruota e affidarsi ai metodi e ai framework esistenti per l'autenticazione. Le JWT hanno avuto la loro quota di sicurezza problemi in passato. leggi altro .
Differenze:
Il problema con il tuo sistema è che il client non può leggere il contenuto del token (ad esempio, quale utente è il proprietario).