Solución:
Me gusta el método de cookies de envío doble XSRF que se menciona en el artículo que dice @ pkid169, pero hay una cosa que el artículo no te dice. Todavía no está protegido contra XSS porque lo que puede hacer el atacante es inyectar un script que lea su cookie CSRF (que no es HttpOnly) y luego realizar una solicitud a uno de sus puntos finales de API utilizando este token CSRF con la cookie JWT que se envía automáticamente.
Entonces, en realidad, todavía es susceptible a XSS, es solo que el atacante no puede robar su token JWT para usarlo más tarde, pero aún puede realizar solicitudes en nombre de sus usuarios utilizando XSS.
Ya sea que almacene su JWT en un localStorage o almacene su token XSRF en una cookie que no sea solo http, ambos pueden ser capturados fácilmente por XSS. Incluso su cookie JWT en HttpOnly puede ser capturada por un ataque XSS avanzado.
Por lo tanto, además del método de cookies de doble envío, siempre debe seguir las mejores prácticas contra XSS, incluido el contenido de escape. Esto significa eliminar cualquier código ejecutable que pueda causar que el navegador haga algo que usted no desea. Normalmente, esto significa eliminar //[CDATA[tagsandHTMLattributesthatcauseJavaScripttobeevaluated
Una publicación oportuna de Stormpath ha elaborado bastante mis puntos y ha respondido a mi pregunta.
TL; DR
Almacene el JWT en cookies, luego pase el JWT en el encabezado de Autorización en cada solicitud como he mencionado, o como sugiere el artículo, confíe en el backend para evitar CSRF (por ejemplo, usando xsrfToken en caso de Angular).
- No almacene su token en LocalStorage o SessionStorage, ya que dicho token se puede leer desde javascript y, por lo tanto, es vulnerable al ataque XSS.
- No almacene su token en Cookie. Cookie (con la bandera HttpOnly) es una mejor opción: es propensa a XSS, pero es vulnerable al ataque CSRF
En cambio, al iniciar sesión, puede entregar dos tokens: token de acceso y token de actualización. El token de acceso debe almacenarse en la memoria Javascript y el token de actualización debe almacenarse en HttpOnly Cookie. El token de actualización se usa solo y solo para crear nuevos tokens de acceso, nada más.
Cuando el usuario abre una nueva pestaña o se actualiza en el sitio, debe realizar una solicitud para crear un nuevo token de acceso, según el token de actualización que se almacena en Cookie.
También recomiendo encarecidamente leer este artículo: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/