¿Almacenar el token de autenticación en una cookie o encabezado?

5

Entiendo que un encabezado es la solución "más limpia" para transportar un token de autenticación de un sistema confiable a otro en una llamada REST. Pero cuando estás en el código JavaScript del lado del cliente, el mundo me parece diferente.

Las cookies se pueden marcar como "solo http" y, por lo tanto, JavaScript no las puede robar fácilmente. Un encabezado incluso tiene que ser configurado por JavaScript, por lo tanto, el token de autenticación debe ser accesible desde JavaScript. Pero aún así, las personas usan encabezados de autenticación para enviar sus tokens de autenticación de un cliente JavaScript no confiable al servidor.

¿Qué ha cambiado desde el antiguo "uso de cookies con solo HTTP y marca de seguridad" para "dejar que el JavaScript maneje el token de autenticación"? ¿O debería ser la forma correcta de que "en el lado del cliente, use cookies y tan pronto como ingrese al mundo de confianza, cambie al encabezado de autenticación"?

PD: Sé que hay muchas respuestas a preguntas similares, pero creo que mis preguntas son desde un punto de vista diferente "lo que ha cambiado, es diferente".

    
pregunta rdmueller 23.02.2018 - 07:43
fuente

1 respuesta

5

Autenticación basada en cookies

Pros

  1. HttpOnly Flag : las cookies de sesión se pueden crear con el HttpOnly que protege las cookies de JavaScript malicioso (XSS-Cross-Site Scripting).

  2. Bandera de seguridad : las cookies de sesión se pueden crear con la bandera de Seguridad que evita la transmisión de cookies a través de un canal no cifrado.

Cons

  1. CSRF : las cookies son vulnerables / susceptibles a los ataques de CSRF ya que las cookies de terceros se envían de forma predeterminada al dominio de terceros que provoca la explotación de la vulnerabilidad de CSRF.

  2. Rendimiento y escalabilidad : la autenticación basada en cookies es una autenticación de estado tal que el servidor tiene que almacenar las cookies en un archivo / DB para mantener el estado de todos los usuarios. A medida que aumenta la base de usuarios, el servidor backend debe mantener un sistema separado para almacenar cookies de sesión.

Autenticación basada en token:

Pros

  1. Rendimiento y escalabilidad : los tokens contienen los metadatos y su valor firmado (para protección contra manipulaciones). Son autocontenidos y, por lo tanto, no hay necesidad de mantener el estado en el servidor. Esto mejora el rendimiento y, por lo tanto, la escalabilidad cuando se requiere la expansión.

  2. CSRF : a diferencia de la autenticación basada en cookies, la autenticación basada en token no es susceptible a la falsificación de solicitud entre sitios, ya que los tokens no se envían a aplicaciones web de terceros de forma predeterminada.

Cons

  1. XSS : dado que los tokens de la sesión se almacenan en el almacenamiento de datos local del navegador y es accesible para el JS del mismo dominio. Por lo tanto, no hay opción para asegurar el identificador de sesión de los ataques XSS a diferencia del indicador de seguridad HTTPOnly que está disponible en la autenticación basada en cookies.

Conclusión

Ambos mecanismos tienen sus propias ventajas y desventajas, como se mencionó. En la era actual de Application Development Frameworks , los contras como XSS y CSRF están a cargo de marco subyacente en sí mismo y, por lo tanto, siento que es sin duda una clara compensación entre los desarrolladores y las partes interesadas que toman la decisión.

    
respondido por el Shiv Sahni 23.02.2018 - 17:33
fuente

Lea otras preguntas en las etiquetas