¿Cuál es la diferencia entre JWT y cifrar algunos json manualmente con AES?

JSON Web Tokens (= JWTs) se basan en RFC 7519 y todas las diferencias se describirán ampliamente allí. Si observa esto, verá que son mucho más de lo que parece tener en mente.
Entre otras cosas, estos tokens:

• se utilizan para afirmar reclamaciones (por ejemplo, "iniciado sesión como administrador")
• están firmados con un código de autenticación de mensaje (por ejemplo, HMAC-SHA256) (el algoritmo se especifica en el encabezado de la JWT)
• tener una carga útil que contenga el (los) reclamo (s) (equipado con una marca de tiempo)

La firma está codificada en base64url. Esto se describe en sección 3.1 y Apéndice A.1 de la RFC.

Podrías hacer todo esto con una implementación elaborada propia de compartir reclamos, pero ¿por qué lo harías?
Hay normas, normas y RFC por una razón. Han sido probados por expertos, son de confianza y la gente los usa por una razón. Es bueno que (casi) todos pesen su fruta en kilos y recorran su distancia en kilómetros. Los sistemas estandarizados facilitan el intercambio de información y son fáciles de usar para muchas personas.

La conclusión a su punto detrás de esto: no cree soluciones demasiado complicadas para los problemas que tienen soluciones probadas y confiables .

^{También: mira esto para otro "¿Cuál es la diferencia ...?" pregunta: ¿Cuál es la diferencia entre el cifrado SHA y AES?}

De mi otra sec.SE respuesta :

  

JWT son tokens autosuficientes que se utilizan para compartir información de autenticación entre diferentes sistemas. Resuelven el problema de confiar en terceros para validar un token de autenticación, ya que toda la información necesaria para validar el JWT está contenida en el token. Esto simplifica el proceso de incorporación en un sistema de inicio de sesión único ya que se requiere una integración mínima. Los JWT también son compatibles con HTTP, ya que son solo cadenas BASE-64.

No ha proporcionado información suficiente sobre la arquitectura de su aplicación. En su caso particular, sería difícil para un tercero o un servidor de recursos de confianza validar el token AES emitido por usted. La única forma de hacerlo sería compartir su clave de cifrado AES con todas las personas que deseen verificar el token de autenticación emitido por usted. Esta sería una mala decisión de diseño que puede tener problemas graves de confidencialidad e integridad.

Además, los tokens deben admitir importantes funciones de seguridad como las marcas de tiempo que permiten que un recurso evite los ataques de reproducción de token. Tu diseño no es compatible con esto.

AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)

Su token de seguridad para el usuario administrador con un ID único 5552 siempre tendrá el mismo valor. En resumen, no debe intentar reinventar la rueda y confiar en los métodos y marcos existentes para la autenticación. Los JWT han tenido su parte de seguridad problemas en el pasado. lea más .

Diferencias:

• JWT envía el texto sin formato y el hmac de la misma, pero en su lugar está enviando el mensaje cifrado
• Los JWT son un estándar y tienen bibliotecas en varios idiomas

El problema con su sistema es que el cliente no puede leer el contenido del token (por ejemplo, qué usuario es el propietario).