Autenticación de token frente a cookies

¿Cuál es la diferencia entre la autenticación de token y la autenticación mediante cookies?

Estoy tratando de implementar la demostración de Ember Auth Rails, pero no entiendo las razones detrás del uso de la autenticación de token como se describe en las preguntas frecuentes de Ember Auth sobre la pregunta "¿Por qué la autenticación de token?"

Una aplicación web típica en su mayoría no tiene estado , debido a su naturaleza de solicitud / respuesta . El protocolo HTTP es el mejor ejemplo de un protocolo sin estado . Pero dado que la mayoría de las aplicaciones web necesitan estado , para mantener el estado , entre el servidor y el cliente, las cookies se utilizan de modo que el servidor pueda enviar cada respuesta al cliente. Esto significa que la próxima solicitud realizada por el cliente incluirá esta cookie y, por lo tanto, será reconocida por el servidor. De esta manera, el servidor puede mantener una sesión con el cliente sin estado , sabiendo principalmente todo sobre el estado de la aplicación , pero almacenado en el servidor. En este escenario en ningún momento el cliente mantieneestado , que no es cómo funciona Ember.js .

En Ember.js las cosas son diferentes. Ember.js facilita el trabajo del programador porque mantiene el estado para usted, en el cliente, sabiendo en todo momento sobre su estado sin tener que hacer una solicitud al servidor solicitando datos de estado .

Sin embargo, mantener el estado en el cliente a veces también puede introducir problemas de concurrencia que simplemente no están presentes en situaciones sin estado . Sin embargo, Ember.js también se ocupa de estos problemas para usted, específicamente ember-data se construye teniendo esto en cuenta. En conclusión, Ember.js es un marco diseñado para clientes con estado .

Ember.js no funciona como una aplicación web sin estado típica donde el servidor maneja la sesión , el estado y las cookies correspondientes casi por completo. Ember.js mantiene su estado completamente en javascript (en la memoria del cliente, y no en el DOM como otros frameworks) y no necesita el servidor para administrar la sesión. Esto hace que Ember.js sea más versátil en muchas situaciones, por ejemplo, cuando su aplicación está en modo fuera de línea.

Obviamente, por razones de seguridad, necesita algún tipo de token o clave única para ser enviada al servidor cada vez que se realiza una solicitud para autenticarse , de esta manera el servidor puede buscar el token de envío (que inicialmente fue emitido por el servidor) y verifique si es válido antes de enviar una respuesta al cliente.

En mi opinión, la razón principal por la que se usa un token de autenticación en lugar de cookies, como se indica en las Preguntas frecuentes de Ember Auth, se debe principalmente a la naturaleza del marco Ember.js y también porque se ajusta más al paradigma de la aplicación web con estado . Por lo tanto, el mecanismo de cookies no es el mejor enfoque al crear una aplicación Ember.js.

Espero que mi respuesta le dé más sentido a su pregunta.

Http no tiene estado. Para autorizarlo, debe "firmar" cada solicitud que envíe al servidor.

Autenticación de token

• Una solicitud al servidor está firmada por un "token"; por lo general, significa configurar encabezados http específicos, sin embargo, se pueden enviar en cualquier parte de la solicitud http (cuerpo POST, etc.)

• Pros:

  • Puede autorizar solo las solicitudes que desea autorizar. (Cookies: incluso las cookies de autorización se envían para cada solicitud).
  • Inmune a XSRF (ejemplo breve de XSRF: le enviaré un enlace por correo electrónico que se verá así <img src="http://bank.com?withdraw=1000&to=myself" />, y si ha iniciado sesión a través de autenticación de cookies en bank.com, y bank.com no tiene ningún medio de XSRF protección, retiraré dinero de su cuenta simplemente por el hecho de que su navegador activará una solicitud GET autorizada a esa url.) Tenga en cuenta que hay medidas antifalsificación que puede hacer con la autenticación basada en cookies, pero debe implementarlas.
  • Las cookies están vinculadas a un solo dominio. Una cookie creada en el dominio foo.com no puede ser leída por el dominio bar.com, mientras que usted puede enviar tokens a cualquier dominio que desee. Esto es especialmente útil para aplicaciones de una sola página que consumen múltiples servicios que requieren autorización, por lo que puedo tener una aplicación web en el dominio myapp.com que puede realizar solicitudes autorizadas del lado del cliente a myservice1.com y myservice2.com.
• Contras:
  • Tienes que almacenar el token en algún lugar; mientras que las cookies se almacenan "fuera de la caja". Las ubicaciones que vienen a la mente son localStorage (con: el token persiste incluso después de cerrar la ventana del navegador), sessionStorage (pro: el token se descarta después de cerrar la ventana del navegador, con: abrir un enlace en una nueva pestaña mostrará esa pestaña anónimo) y cookies (Pro: el token se descarta después de cerrar la ventana del navegador. Si usa una cookie de sesión, se autenticará al abrir un enlace en una nueva pestaña, y es inmune a XSRF ya que ignora el cookie para autenticación, solo la está utilizando como almacenamiento de tokens. Con: las cookies se envían para cada solicitud. Si esta cookie no está marcada solo como https, está abierto para ataques de hombre en el medio.)
  • Es un poco más fácil hacer un ataque XSS contra la autenticación basada en tokens (es decir, si puedo ejecutar un script inyectado en su sitio, puedo robar su token; sin embargo, la autenticación basada en cookies tampoco es una bala de plata, mientras que las cookies marcadas como http-only no puede ser leído por el cliente, el cliente aún puede hacer solicitudes en su nombre que incluirán automáticamente la cookie de autorización).
  • Las solicitudes para descargar un archivo, que se supone que funciona solo para usuarios autorizados, requieren que utilice la API de archivos. La misma solicitud sale de la caja para la autenticación basada en cookies.

Autenticación de cookies

• Una solicitud al servidor siempre se registra mediante una cookie de autorización.
• Pros:
  • Las cookies pueden marcarse como "solo http", lo que hace que sea imposible leerlas en el lado del cliente. Esto es mejor para la protección contra ataques XSS.
  • Sale de la caja: no tiene que implementar ningún código en el lado del cliente.
• Contras:
  • Vinculado a un solo dominio. (Entonces, si tiene una aplicación de una sola página que realiza solicitudes a múltiples servicios, puede terminar haciendo cosas locas como un proxy inverso).
  • Vulnerable a XSRF. Debe implementar medidas adicionales para proteger su sitio contra la falsificación de solicitudes entre sitios.
  • Se envían para cada solicitud individual (incluso para solicitudes que no requieren autenticación).

En general, diría que los tokens te dan una mayor flexibilidad (ya que no estás vinculado a un solo dominio). La desventaja es que tienes que codificar un poco tú solo.

• Los tokens deben almacenarse en algún lugar (almacenamiento local / de sesión o cookies)

• Los tokens pueden caducar como las cookies, pero tienes más control

• El almacenamiento local / de sesión no funcionará en todos los dominios, use una cookie de marcador

• Las solicitudes de verificación previa se enviarán en cada solicitud CORS

• Cuando necesite transmitir algo, use el token para obtener una solicitud firmada

• Es más fácil lidiar con XSS que XSRF

• El token se envía en cada solicitud, ten cuidado con su tamaño

• Si almacena información confidencial, cifre el token

• Los tokens web JSON se pueden usar en OAuth

• Los tokens no son balas de plata, piense detenidamente en sus casos de uso de autorización

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Para Googlers :

• NO mezcle el estado con mecanismos de transferencia de estado

Estabilidad

• Stateful = guardar información de autorización en el lado del servidor, esta es la forma tradicional
• Sin estado = guardar información de autorización en el lado del cliente, junto con una firma para garantizar la integridad

Mecanismos

• Cookie = un encabezado especial con tratamiento especial (acceso, almacenamiento, caducidad, seguridad, transferencia automática) por parte de los navegadores
• Encabezados personalizados = por ejemplo Authorization, son solo encabezados sin ningún tratamiento especial, el cliente debe administrar todos los aspectos de la transferencia
• Otro . Se pueden utilizar otros mecanismos de transferencia, por ejemplo, la cadena de consulta fue una opción para transferir ID de autenticación durante un tiempo, pero se abandonó por su inseguridad.

COMPARACIÓN DE ESTATUS

• "Autorización con estado" significa que el servidor almacena y mantiene la información de autorización del usuario en el servidor, haciendo que las autorizaciones formen parte del estado de la aplicación
• Esto significa que el cliente solo necesita mantener una "ID de autenticación" y el servidor puede leer los detalles de autenticación de su base de datos
• Esto implica que el servidor mantiene un grupo de autenticaciones activas (usuarios que han iniciado sesión) y consultará esta información para cada solicitud
• "Autorización sin estado" significa que el servidor no almacena ni mantiene la información de autenticación del usuario, simplemente no sabe qué usuarios han iniciado sesión y confía en el cliente para producir la información de autenticación
• El cliente almacenará información de autenticación completa como quién es usted (ID de usuario) y posiblemente permisos, tiempo de vencimiento, etc., esto es más que solo ID de autenticación, por lo que se le asigna un nuevo token de nombre
• Obviamente, no se puede confiar en el cliente, por lo que los datos de autenticación se almacenan junto con una firma generada desde hash(data + secret key), donde el servidor solo conoce la clave secreta, por lo que se puede verificar la integridad de los datos del token
• Tenga en cuenta que el mecanismo de token simplemente garantiza la integridad, pero no la confidencialidad, el cliente tiene que implementar ese
• Esto también significa que para cada solicitud, el cliente debe enviar un token completo, lo que implica un ancho de banda adicional

COMPARACIÓN MECANISMO

• "Cookie" es solo un encabezado, pero con algunas operaciones precargadas en los navegadores
• La cookie puede ser configurada por el servidor y guardada automáticamente por el cliente, y se enviará automáticamente para el mismo dominio
• La cookie se puede marcar httpOnlypara evitar el acceso de JavaScript del cliente
• Las operaciones precargadas pueden no estar disponibles en plataformas que no sean navegadores (por ejemplo, dispositivos móviles), lo que puede llevar a esfuerzos adicionales
• Los "encabezados personalizados" son solo encabezados personalizados sin operaciones precargadas
• El cliente es responsable de recibir, almacenar, proteger, enviar y actualizar la sección de encabezado personalizado para cada solicitud, esto puede ayudar a prevenir la inclusión de URL maliciosas simples

RESUMIR

• No hay magia, el estado de autenticación debe almacenarse en algún lugar, ya sea en el servidor o en el cliente
• Puede implementar con estado / sin estado con cookies u otros encabezados personalizados
• Cuando la gente habla de esas cosas, su mentalidad predeterminada es principalmente: sin estado = token + encabezado personalizado, con estado = ID de autenticación + cookie; estas NO son las únicas opciones posibles
• Tienen pros y contras, pero incluso para los tokens encriptados no debes almacenar información confidencial

Enlace

Creo que hay algo de confusión aquí. La diferencia significativa entre la autenticación basada en cookies y lo que ahora es posible con HTML5 Web Storage es que los navegadores están diseñados para enviar datos de cookies cada vez que solicitan recursos del dominio que los configuró. No puede evitar eso sin desactivar las cookies. Los navegadores no envían datos desde el almacenamiento web a menos que el código en la página lo envíe . Y las páginas solo pueden acceder a los datos que almacenaron, no a los datos almacenados por otras páginas.

Entonces, un usuario preocupado por la forma en que Google o Facebook podrían usar sus datos de cookies podría desactivar las cookies. Pero tienen menos razones para desactivar el almacenamiento web (hasta que los anunciantes encuentren una forma de usar eso también).

Entonces, esa es la diferencia entre las cookies y las basadas en tokens, este último usa almacenamiento web.

La autenticación basada en tokens no tiene estado, el servidor no necesita almacenar información del usuario en la sesión. Esto brinda la capacidad de escalar la aplicación sin preocuparse de dónde ha iniciado sesión el usuario. Existe afinidad de Web Server Framework por las cookies, mientras que eso no es un problema con el token basado. Por lo tanto, se puede usar el mismo token para obtener un recurso seguro de un dominio que no sea el que estamos conectados, lo que evita otra autenticación uid / pwd.

Muy buen artículo aquí:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Usar token cuando ...

Se desea la federación. Por ejemplo, desea usar un proveedor (Token Dispensor) como emisor de tokens, y luego usar su servidor api como validador de tokens. Una aplicación puede autenticarse en Token Dispensor, recibir un token y luego presentar ese token a su servidor api para ser verificado. (Lo mismo funciona con Google Sign-In. O Paypal. O Salesforce.com. Etc.)

Se requiere asincronía. Por ejemplo, desea que el cliente envíe una solicitud y luego almacene esa solicitud en algún lugar para que un sistema separado actúe "más tarde". Ese sistema separado no tendrá una conexión síncrona con el cliente y es posible que no tenga una conexión directa con un dispensador central de tokens. El sistema de procesamiento asincrónico puede leer un JWT para determinar si el elemento de trabajo puede y debe cumplirse en ese momento posterior. Esto está, en cierto modo, relacionado con la idea de la Federación anterior. Sin embargo, tenga cuidado aquí: JWT caduca. Si la cola que contiene el elemento de trabajo no se procesa durante la vida útil del JWT, entonces no se debe confiar en las reclamaciones.

Se requiere solicitud firmada por el cliente. Aquí, el cliente firma la solicitud con su clave privada y el servidor la validaría con la clave pública ya registrada del cliente.

Una de las principales diferencias es que las cookies están sujetas a la Política del mismo origen, mientras que los tokens no. Esto crea todo tipo de efectos descendentes.

Dado que las cookies solo se envían desde y hacia un host en particular, ese host debe asumir la carga de autenticar al usuario y el usuario debe crear una cuenta con datos de seguridad con ese host para que sea verificable.

Los tokens, por otro lado, se emiten y no están sujetos a la misma política de origen. El emisor puede ser literalmente cualquier persona y depende del host decidir en qué emisores confiar. Un emisor como Google y Facebook generalmente es de confianza, por lo que un host puede trasladar la carga de autenticar al usuario (incluido el almacenamiento de todos los datos de seguridad del usuario) a otra parte y el usuario puede consolidar sus datos personales bajo un emisor específico y no tener que recordar un Un montón de contraseñas diferentes para cada host con el que interactúan.

Esto permite escenarios de inicio de sesión único que reducen la fricción general en la experiencia del usuario. En teoría, la web también se vuelve más segura a medida que los proveedores de identidad especializados emergen para proporcionar servicios de autenticación en lugar de tener cada sitio web ma and pa haciendo girar sus propios sistemas de autenticación, probablemente a medias. Y a medida que estos proveedores emergen, el costo de proporcionar recursos web seguros incluso para las tendencias de recursos muy básicos hacia cero.

Por lo tanto, en general, los tokens reducen la fricción y los costos asociados con el suministro de autenticación y transfieren la carga de los diversos aspectos de una web segura a partes centralizadas que pueden implementar y mantener sistemas de seguridad mejor.