Leí algunas publicaciones sobre "JWT vs Cookie" pero solo me confundieron más ...

1. Quiero una aclaración , cuando la gente habla de "autenticación basada en tokens frente a cookies", ¿las cookies aquí simplemente se refieren a las cookies de sesión ? Tengo entendido que la cookie es como un medio , se puede usar para implementar una autenticación basada en token (almacenar algo que pueda identificar al usuario que inició sesión en el lado del cliente ) o una autenticación basada en sesión (almacenar una constante en el lado del cliente que coincide con la información de la sesión en el lado del servidor )

2. ¿Por qué necesitamos el token web JSON ? Estaba usando la cookie estándar para implementar la autenticación basada en token ( sin usar la identificación de sesión, no usar la memoria del servidor o el almacenamiento de archivos ): Set-Cookie: user=innocent; preferred-color=azurey la única diferencia que observé es que JWT contiene tanto la carga útil como la firma ... mientras que usted puede elegir entre la cookie firmada o de texto sin formato para el encabezado http. En mi opinión, la cookie firmada ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') es más eficiente en el espacio, el único inconveniente es que el cliente no puede leer el token, solo el servidor puede ... pero creo que está bien porque, al igual que la reclamación en JWT es opcional, no es necesario que el token ser significativo

La mayor diferencia entre los tokens de portador y las cookies es que el navegador enviará cookies automáticamente , donde los tokens de portador deben agregarse explícitamente a la solicitud HTTP.

Esta función hace que las cookies sean una buena forma de proteger los sitios web, donde un usuario inicia sesión y navega entre páginas mediante enlaces.

El navegador que envía cookies automáticamente también tiene una gran desventaja, que son los ataques CSRF . En un ataque CSRF, un sitio web malintencionado aprovecha el hecho de que su navegador adjuntará automáticamente cookies de autenticación a las solicitudes de ese dominio y engañará a su navegador para que ejecute una solicitud.

Suponga que el sitio web en https://www.example.com permite que los usuarios autenticados cambien sus contraseñas al cambiar POSTla nueva contraseña a https://www.example.com/changepassword sin requerir que se publique el nombre de usuario o la contraseña anterior.

Si aún ha iniciado sesión en ese sitio web cuando visita un sitio web malicioso que carga una página en su navegador que activa una POST a esa dirección, su navegador adjuntará fielmente las cookies de autenticación, lo que permitirá al atacante cambiar su contraseña.

Las cookies también se pueden utilizar para proteger los servicios web, pero hoy en día los tokens de portador se utilizan con mayor frecuencia. Si utiliza cookies para proteger su servicio web, ese servicio debe residir en el dominio para el que están configuradas las cookies de autenticación, ya que la política del mismo origen no enviará cookies a otro dominio.

Además, las cookies dificultan que las aplicaciones no basadas en navegador (como las aplicaciones de móvil a tableta) consuman su API.

Visión general

Lo que está pidiendo es la diferencia entre las cookies y los tokens de portador para enviar tokens web JSON (JWT) del cliente al servidor.

Tanto las cookies como los tokens de portador envían datos.

Una diferencia es que las cookies son para enviar y almacenar datos arbitrarios, mientras que los tokens de portador son específicamente para enviar datos de autorización.

A menudo, esos datos se codifican como JWT.

Galleta

Una cookie es un par de nombre-valor, que se almacena en un navegador web y que tiene una fecha de vencimiento y un dominio asociado.

Almacenamos cookies en un navegador web con JavaScript o con un encabezado de respuesta HTTP.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

El navegador web envía automáticamente cookies con cada solicitud al dominio de la cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Token de portador

Un token de portador es un valor que se incluye en el Authorizationencabezado de cualquier solicitud HTTP. No se almacena automáticamente en ningún lugar, no tiene fecha de caducidad ni dominio asociado. Es solo un valor. Almacenamos manualmente ese valor en nuestros clientes y lo agregamos manualmente al encabezado de Autorización HTTP.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

Autenticación basada en token y JWT

Cuando realizamos una autenticación basada en tokens, como OpenID, OAuth u OpenID Connect, recibimos un access_token (y a veces id_token) de una autoridad confiable. Por lo general, queremos almacenarlo y enviarlo junto con solicitudes HTTP para recursos protegidos. ¿Como hacemos eso?

La opción 1 es almacenar el (los) token (s) en una cookie. Esto maneja el almacenamiento y también envía automáticamente el (los) token (s) al servidor en el Cookieencabezado de cada solicitud. Luego, el servidor analiza la cookie, verifica los token (s) y responde en consecuencia.

Otra opción es almacenar el token en el almacenamiento local / de sesión y luego configurar manualmente el Authorizationencabezado de cada solicitud. En este caso, el servidor lee el encabezado y procede como con una cookie.

Vale la pena leer las RFC vinculadas para obtener más información.

Además de lo que MvdD ha dicho sobre el envío automático de cookies:

1. Una cookie puede ser un medio, pero su función más importante es cómo interactúa con el navegador. Las cookies son establecidas por el servidor y enviadas en solicitudes de formas muy específicas. JWT por otro lado es exclusivamente un medio, es una afirmación de algunos hechos en una estructura particular. Si lo desea, puede poner un JWT como su cookie de autenticación. Cuando lee artículos que los comparan, generalmente se refieren al uso de un JWT enviado como un token de portador por el código del front-end frente a una cookie de autenticación que corresponde a alguna sesión en caché o datos de usuario en el back-end.
2. JWT ofrece muchas funciones y las coloca en un estándar para que puedan usarse entre las partes. Un JWT puede actuar como una afirmación firmada de algunos hechos en muchos lugares diferentes. Una cookie, independientemente de los datos que introduzca en ella o si la firma, solo tiene sentido utilizarla entre un navegador y un back-end específico. JWT se puede utilizar desde el navegador hasta el back-end, entre los back-end controlados por diferentes partes (OpenId Connect es un ejemplo) o dentro de los servicios de back-end de una parte. Con respecto a su ejemplo específico de sus cookies firmadas, probablemente pueda lograr las mismas funciones ("no usar la identificación de sesión, no usar la memoria del servidor o el almacenamiento de archivos") que JWT en ese caso de uso, pero pierde bibliotecas y revisión por pares de el estándar, además de los problemas CSRF de los que se habla en la otra respuesta.

En resumen: las publicaciones que está leyendo probablemente comparen JWT como un token de portador con una cookie de autenticación para fines de autenticación del navegador y del servidor. Pero JWT puede hacer mucho más, trae estandarización y características para usar fuera del caso de uso en el que probablemente esté pensando.

Si bien las cookies pueden aumentar el riesgo de ataques CSRF en virtud de que se envían automáticamente junto con las solicitudes, pueden disminuir el riesgo de ataques XSS cuando HttpOnlyse establece la bandera, porque cualquier script que se inyecte en la página no podrá leer La galleta.

CSRF: un usuario hace clic en un enlace (o ve imágenes) en el sitio de un atacante, lo que hace que el navegador envíe una solicitud al sitio de la víctima. Si la víctima usa cookies, el navegador incluirá automáticamente la cookie en la solicitud, y si la solicitud GET puede causar acciones que no sean de solo lectura, el sitio de la víctima es vulnerable al ataque.

XSS: un atacante inserta una secuencia de comandos en el sitio de la víctima (el sitio de la víctima solo es vulnerable si las entradas no se desinfectan correctamente), y la secuencia de comandos del atacante puede hacer cualquier cosa que JavaScript pueda hacer en la página. Si almacena tokens JWT en el almacenamiento local, el script del atacante podría leer esos tokens y también enviar esos tokens a un servidor que controlan. Si usa cookies con la HttpOnlybandera, el script del atacante no podrá leer su cookie para empezar. Dicho esto, la secuencia de comandos que inyectaron con éxito aún podrá hacer cualquier cosa que pueda hacer javascript, por lo que aún está conectado en mi opinión (es decir, aunque es posible que no puedan leer la cookie para enviarla a su propio servidor para usarla más adelante , pueden enviar solicitudes al sitio vicitim utilizando XHR, que de todos modos incluirá la cookie).

Ref: Necesidad de un token web JSON

Galletas

En el caso de las cookies, una vez que el usuario ha sido autenticado, el servidor de Gmail creará una identificación de sesión única. En correspondencia con este id de sesión, almacenará en la memoria toda la información de usuario que necesita el servidor de Gmail para reconocer al usuario y permitirle realizar operaciones.
Además, para todas las solicitudes y respuestas posteriores, también se pasará esta identificación de sesión. Entonces, cuando el servidor reciba una solicitud, verificará la identificación de la sesión. El uso de esta identificación de sesión verificará si hay alguna información correspondiente. Luego permitirá al usuario acceder al recurso y devolver la respuesta junto con la identificación de la sesión.

Inconvenientes de las cookies

• Las cookies / ID de sesión no son independientes. Es un token de referencia. Durante cada validación, el servidor de Gmail necesita obtener la información correspondiente.
• No apto para arquitectura de microservicios que involucre múltiples API y servidores

JWT

• JWT es autónomo. Es una ficha de valor. Por lo tanto, durante cada validación, el servidor de Gmail no necesita obtener la información correspondiente.
• Está firmado digitalmente, por lo que si alguien lo modifica, el servidor lo sabrá.
• Es más adecuado para la arquitectura de microservicios.
• Tiene otras ventajas como especificar el tiempo de caducidad.