Pregunta Autenticación Token vs. Cookies


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

Estoy tratando de implementar Ember Auth Rails Demo pero no entiendo las razones detrás de usar la autenticación de token como se describe en el Preguntas frecuentes sobre Ember Auth sobre la pregunta "¿Por qué autenticación de token?"


74
2018-06-08 15:07


origen


Respuestas:


Una aplicación web típica es principalmente apátrida, debido a su solicitar respuesta naturaleza. El protocolo HTTP es el mejor ejemplo de apátrida protocolo. Pero como la mayoría de las aplicaciones web necesitan estado, para sostener el estado, entre el servidor y el cliente, las cookies se utilizan de tal manera que el servidor puede enviar todas las respuestas al cliente. Esto significa que la siguiente solicitud hecha desde el cliente incluirá esta cookie y así será reconocida por el servidor. De esta forma, el servidor puede mantener un sesión con el apátrida cliente, sabiendo casi todo sobre la aplicación estado, pero almacenado en el servidor. En este escenario, en ningún momento el cliente espera estado, que no es como Ember.js trabajos.

En Ember.js las cosas son diferentes. Ember.js hace que el trabajo del programador sea más fácil porque contiene de hecho el estado para ti, en el cliente, sabiendo en todo momento que es estado sin tener que hacer una solicitud al servidor solicitando estado datos.

Sin embargo, sosteniendo estado en el cliente también a veces puede presentar problemas de concurrencia que simplemente no están presentes en apátrida situaciones Ember.js, sin embargo, también se ocupa de estos problemas para usted, específicamente los datos de asamblea se construyen con esto en mente. En conclusión, Ember.js es un marco diseñado para con estado clientela.

Ember.js no funciona como un típico apátrida aplicación web donde el sesión, el estado y las cookies correspondientes son manejadas casi por completo por el servidor. Ember.js sostiene que es estado completamente en javascript (en la memoria del cliente, y no en el DOM como algunos otros marcos) y no necesita el servidor para administrar la sesión. Esto hace que Ember.js sea más versátil en muchas situaciones, p. cuando tu aplicación está en modo fuera de línea

Obviamente, por razones de seguridad, necesita algún tipo de simbólico o llave unica para ser enviado al servidor cada vez que se realiza una solicitud para ser autenticado, de esta forma, el servidor puede buscar el token de envío (que fue emitido inicialmente por el servidor) y verificar si es válido antes de enviar una respuesta al cliente.

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

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


21
2018-06-08 15:50



Http es apátrida. Para poder autorizarlo, debe "firmar" cada solicitud que envía al servidor.

Autenticación de tokens

  • Una solicitud al servidor está firmada por un "token", generalmente significa el establecimiento de 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 la cookie de autorización se envía para cada solicitud).
    • Inmune a XSRF (Ejemplo corto de XSRF: le enviaré un enlace en un correo electrónico que se verá como <img src="http://bank.com?withdraw=1000&to=myself" />, y si ha iniciado sesión mediante la autenticación de cookies a bank.com, y bank.com no tiene ningún medio de protección XSRF, retiraré dinero de su cuenta simplemente por el hecho de que su navegador activará un GET autorizado. solicite a esa url.) Tenga en cuenta que hay medidas anti falsificación que puede hacer con la autenticación basada en cookies, pero debe implementarlas.
    • Las cookies están ligadas 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 pueda realizar solicitudes autorizadas del lado del cliente a myservice1.com y a myservice2.com.
  • Contras:
    • Tienes que guardar el token en algún lugar; mientras que las cookies se almacenan "fuera de la caja". Las ubicaciones que te vienen a la mente son localStorage (con: el token se conserva 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 representará esa pestaña anonymous) 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 usted es inmune a XSRF ya que está ignorando el cookie para autenticación, solo lo está utilizando como almacenamiento simbólico. Con: se envían cookies para cada solicitud. Si esta cookie no está marcada solo como https, está abierto para los intermediarios.
    • Es ligeramente 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 están marcadas como El cliente no puede leer solo http, el cliente aún puede realizar solicitudes en su nombre que incluirán automáticamente la cookie de autorización.
    • Las solicitudes para descargar un archivo, que se supone que solo funciona para usuarios autorizados, requieren que use File API. La misma solicitud funciona de la caja para la autenticación basada en cookies.

Autenticación de cookies

  • Una solicitud al servidor siempre se inicia con una cookie de autorización.
  • Pros:
    • Las cookies se pueden marcar como "http-only", lo que hace imposible su lectura en el lado del cliente. Esto es mejor para la protección de ataque XSS.
    • Se saca 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, (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 obligado a un solo dominio). El inconveniente es que tienes que hacer un poco de codificación por ti mismo.


151
2018-01-28 11:10



  • Los tokens deben almacenarse en algún lugar (almacenamiento local o 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 de CORS

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

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

  • El token se envía en cada solicitud, 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 una bala de oro, piense detenidamente en sus casos de uso de autorizaciones

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/


29
2018-04-02 15:38



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 Almacenamiento web HTML5 es que los navegadores están diseñados para enviar datos de cookies cada vez que solicitan recursos del dominio que los establece. No puede evitar eso sin desactivar las cookies. Navegadores no envíe datos del 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 almacenados, no a los datos almacenados en otras páginas.

Por lo tanto, un usuario preocupado por la forma en que sus datos de cookies podrían ser utilizados por Google o Facebook podría desactivar las cookies. Sin embargo, tienen menos motivos para desactivar el almacenamiento web (hasta que los anunciantes encuentren una forma de usarlo también).

Entonces, esa es la diferencia entre la basada en cookies y la basada en token, esta última usa almacenamiento web.


8
2017-12-27 08:14



La autenticación basada en tokens es sin estado, el servidor no necesita almacenar información del usuario en la sesión. Esto le da la capacidad de escalar la aplicación sin preocuparse de dónde ha iniciado sesión el usuario. Existe afinidad con el marco de trabajo del servidor web para las cookies, mientras que eso no es un problema con token. Entonces, el mismo símbolo se puede usar para obtener un recurso seguro de un dominio distinto al que estamos registrados, lo que evita otra autenticación de 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


3
2018-03-27 10:52



Una de las principales diferencias es que las cookies están sujetas a la misma política de origen, mientras que las tokens no lo son. Esto crea todo tipo de efectos de flujo descendente.

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

Las fichas, por otro lado, se emiten y no están sujetas a la misma política de origen. El emisor puede ser literalmente cualquiera y le corresponde al anfitrión decidir en qué emisores confiar. Normalmente, un emisor como Google y Facebook 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 surgen proveedores de identidad especializados para proporcionar servicios de autenticación, en lugar de tener cada sitio web de ma y de pa hilando sus propios sistemas de autenticación, probablemente a medio cocinar. Y a medida que estos proveedores surgen 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 la provisión de autenticación y trasladan la carga de los diversos aspectos de una web segura a partes centralizadas que pueden implementar y mantener sistemas de seguridad.


0
2017-07-15 02:47