ejemplo - json web token c#

JWT vs cookies para autenticación basada en token

Question

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

1. Quiero alguna aclaración , cuando las personas que hablan de "autenticación basada en token frente a cookies", ¿las cookies aquí simplemente se refieren a cookies de sesión ? Tengo entendido que la cookie es como un medio , puede usarse para implementar una autenticación basada en token (almacenar algo que pueda identificar al usuario conectado 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 la sesión, no usar la memoria del servidor o el almacenamiento de archivos ): Set-Cookie: user=innocent; preferred-color=azure Set-Cookie: user=innocent; preferred-color=azure , y la única diferencia que observé es que JWT contiene carga útil y firma ... mientras que puede elegir entre 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 cuanto al 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 el reclamo en JWT es opcional, no es necesario que el token sea significativo

Answer 1

Visión de conjunto

Lo que está pidiendo es la diferencia entre las cookies y los tokens de soporte para enviar JSON Web Tokens (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.

Esos datos a menudo se codifican como un JWT.

Cookie

Una cookie es un par de nombre y 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 al portador

Un token de portador es un valor que va al encabezado de Authorization 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 agregamos manualmente ese valor al encabezado de Autorización HTTP.

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

JWT y autenticación basada en tokens

Cuando hacemos autenticación basada en token, 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 las solicitudes HTTP de recursos protegidos. ¿Como hacemos eso?

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

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

Vale la pena leer los RFC vinculados para obtener más información.

Answer 2

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 estuviera tan inclinado, podría poner un JWT como su cookie de autenticación. Cuando lee artículos que los comparan, generalmente hablan de usar un JWT enviado como token de portador por código frontal 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 pone 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 ingrese o si la firma, solo tiene sentido usarla entre un navegador y un back-end específico. JWT se puede usar desde el navegador hasta el back-end, entre 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 cookies firmadas, probablemente pueda lograr las mismas funciones ("no usar la identificación de la sesión, no usar la memoria del servidor o el almacenamiento de archivos") que JWT en ese caso de uso, pero pierde las bibliotecas y la revisión por pares de el estándar, además de los problemas CSRF mencionados en la otra respuesta.

En resumen: las publicaciones que está leyendo probablemente estén comparando JWT como un token portador con una cookie de autenticación para fines de autenticación del navegador al 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.

Answer 3

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 característica hace que las cookies sean una buena manera de proteger los sitios web, donde un usuario inicia sesión y navega entre páginas usando enlaces.

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

Supongamos que el sitio web en https://www.example.com permite que los usuarios autenticados cambien sus contraseñas POST -enviando la 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 está conectado a 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, permitiendo que el atacante cambie su contraseña.

Las cookies también se pueden usar para proteger los servicios web, pero hoy en día los tokens de portador se usan con mayor frecuencia. Si usa cookies para proteger su servicio web, ese servicio debe vivir 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 hacen que sea más difícil para las aplicaciones que no están basadas en el navegador (como las aplicaciones móviles a las tabletas) consumir su API.