El mejor lugar para almacenar tokens de autenticación del lado del cliente

Hay dos formas de guardar la información de autenticación en el navegador:

1. Cookies
2. Almacenamiento web HTML5

En cada caso, debe confiar en que los navegadores se implementan correctamente y que el sitio web A no puede acceder de alguna manera a la información de autenticación del sitio web B. En ese sentido, ambos mecanismos de almacenamiento son igualmente seguros. Sin embargo, pueden surgir problemas en cuanto a cómo los usas.

Si utiliza cookies:

• El navegador enviará automáticamente la información de autenticación con cada solicitud a la API. Esto puede ser conveniente siempre y cuando sepas que está sucediendo.
• Tienes que recordar que CSRF es una cosa y lidiar con eso.

Si usas almacenamiento web HTML5:

• Debe escribir un Javascript que administre exactamente cuándo y qué información de autenticación se envía.

La gran diferencia que a la gente le importa es que con las cookies, tiene que preocuparse por CSRF. Para manejar CSRF correctamente, normalmente necesita un "token de sincronizador" adicional .

Los marcos web todo en uno (como Grails, Rails, probablemente asp.net) suelen proporcionar una forma fácil de habilitar la protección CSRF y agregar automáticamente elementos de token de sincronizador en su interfaz de usuario. Pero si está escribiendo una interfaz de usuario utilizando un marco web solo para el cliente (como AngularJS o BackboneJS), tendrá que escribir algo de Javascript para administrar el token del sincronizador. Por lo tanto, en ese caso, también puede ir con el enfoque de almacenamiento web HTML5 y solo preocuparse por un token.

Se discuten otras diferencias aquí .

editar una búsqueda en Google revela this para asp.net: llaman al token del sincronizador un" token de verificación de solicitud ".

La forma más segura de almacenar su token de acceso es simplemente no almacenarlo del lado del cliente.

¿Cómo funciona eso? Bien en el punto de generar el token de acceso, genere algún otro PRNG criptográficamente seguro (que asigna al token de acceso en el token de acceso). servidor), asigne esto al ID de sesión de los usuarios y devuélvalo al cliente en su lugar.

Esto reducirá el área de ataque porque lo que está devolviendo ahora es un token vinculado a una sesión, y ambos serían necesarios para autorizar el token. Cuando la sesión expira, el token también lo hace, naturalmente, y el usuario se vería obligado a volver a autenticarse para generar un nuevo token de acceso.

Todavía no es 100% seguro, sin embargo, debe sopesar la posibilidad de que algo así suceda dentro de una sesión de usuarios. En base a eso, puede ajustar los tiempos de caducidad de su sesión / token para que se adapten, aunque también debe estar cansado de la facilidad de uso. No desea que caduquen las sesiones después de 5 minutos, ya que tener que volver a iniciar sesión constantemente puede ser tedioso ( o tal vez puedas, depende del tipo de aplicación).

ARMOR está diseñado específicamente para cumplir con este requisito. El token de Anti-falsificación se puede almacenar en cualquier lugar de la interfaz de usuario que considere oportuno. La biblioteca viene equipada con un componente de JavaScript personalizado que extrae el token de la interfaz de usuario y lo incluye automáticamente en los encabezados de AJAX.

Aquí hay un tutorial sobre el tema, y aquí está el repositorio de GitHub .

El blog de Alex debe ser informativo.

  

Un servidor muere cada vez que alguien implementa OAuth en una sola página es   Aplicación Web. ¡Para el genocidio! Utilice un servidor proxy de lado! ¡Actúa ahora!

enlace

Debe enviar el token al servidor en cada requset. Por lo tanto, no importa que lo almacene en un almacenamiento de cookies o html 5. Ambos son almacenamientos seguros y todos los que tienen acceso a la máquina cliente también tienen acceso al token también.

Pero recomiendo que no use el token enviado en la cookie de su servidor para evitar el ataque CSRF. Creo que es una buena idea incluir manualmente el token en cada solicitud que realice cuando sea necesario.

El uso de cookies también hace que el encabezado de la solicitud sea más grande, lo que no es apropiado.