Los cinco hermanos que debes conocer sobre la autenticación: cookie, sesión, token, jwt e inicio de sesión único.
* *"Almacenamiento frontal"* *Esto implica un motor, un almacenamiento y un área, que es fácil de enviar. La interfaz de inicio de sesión regresa directamente al front-end, por lo que el front-end necesita encontrar una manera de almacenarla.
La interfaz tiene múltiples métodos de almacenamiento.
Sí, galletas. Las cookies también son un tipo de almacenamiento de front-end, pero en comparación con otros métodos como localStorage, con la ayuda de encabezados HTTP y capacidades del navegador, las cookies pueden volverse invisibles para el front-end. El proceso general es el siguiente:
"Configuración: Dominio/Ruta"
Las cookies se utilizan para limitar:: "alcance del espacio"::, y pasan por dos niveles: dominio/ camino.
"Configuración: Caducidad/Periodo Máximo"
Las cookies también se pueden limitar a: "Rango de Tiempo": uno de "Tiempo de Caducidad" y "Tiempo Máximo de Uso".
"Configuración: Seguridad/HttpOnly"
Se pueden restringir las cookies:: "Uso"::.
* *"Cookies de lectura y escritura de encabezados HTTP"* *Mirando hacia atrás, ¿cómo lee, escribe y transfiere HTTP las cookies y su configuración? Utilice un encabezado Set-cookie devuelto por HTTP para escribir "una (y sólo una)" cookie en el navegador, en el formato de valor de clave de configuración de valor de clave de cookie. Por ejemplo:
¿Qué pasa si quiero configurar más cookies a la vez? Proporcione más encabezados Set-Cookie (se permite la duplicación en solicitudes HTTP).
El navegador utiliza el encabezado Cookie de la solicitud HTTP para enviar al servidor todas las cookies que coincidan con la configuración actual de "espacio, tiempo y uso". Debido a que el navegador ya ha realizado un juicio de filtrado, no es necesario devolver el contenido de la configuración, solo es necesario enviar el valor clave.
* *"Cookies de lectura y escritura del front-end"* *El front-end puede crear cookies por sí mismo. Si la cookie creada por el servidor no agrega HttpOnly, felicidades, también puedes modificar la cookie que proporcionó. Las cookies se pueden crear y modificar llamando a document.cookie. Al igual que HTTP, document.cookie puede y solo puede operar con una cookie a la vez.
Las cookies también se pueden leer llamando a document.cookie. Al igual que HTTP, se pueden leer todas las cookies que no sean HttpOnly.
Ahora piénsalo, ¿qué pasó cuando pasaste tu tarjeta?
Esta operación se denomina sesión en los sistemas de autenticación front-end y back-end. Proceso típico de inicio de sesión/autenticación:
* *"Método de almacenamiento de sesión"* *Obviamente, el servidor solo proporciona a la cookie un ID de sesión y el contenido específico de la sesión (puede incluir información del usuario, estado de la sesión, etc.) Debería haberlo guardado él mismo. Existen varios métodos de almacenamiento:
"Caducidad y destrucción de la sesión"* *Muy simple, simplemente destruye los datos de la sesión almacenados. * * * *"Problema de distribución de sesiones"* *Normalmente, el servidor es un clúster y se adoptará un equilibrio de carga cuando el usuario lo solicite, no necesariamente en qué máquina. Entonces, una vez que la máquina solicitada por la interfaz posterior del usuario no coincide con la máquina que solicitó iniciar sesión, o la máquina que solicitó iniciar sesión deja de funcionar, ¿no será inválida la sesión? Ahora existen varias soluciones a este problema.
Pero generalmente se adopta el primer método, porque el segundo método equivale a castrar el equilibrio de carga y aún no resuelve el problema del "tiempo de inactividad de la máquina solicitado por los usuarios". * * "Procesamiento de sesiones en node.js" * * La imagen anterior ya es muy clara. El servidor todavía tiene mucho que hacer para acceder a las cookies y las sesiones. En npm, ya existe middleware empaquetado, como express-session-npm, por lo que no se anuncia su uso.
Esta es su cookie:
La implementación principal de fast session npm:
El mantenimiento de sesiones causa muchos problemas al servidor. Tenemos que encontrar un lugar para almacenarlo, considerar problemas de distribución e incluso habilitar un clúster de Redis separado para él. ¿Existe una mejor manera?
Mirando hacia atrás, un escenario de inicio de sesión no necesita almacenar demasiadas cosas en la sesión, ¿por qué no simplemente empaquetarlo en una cookie? De esta manera, el servidor no necesita guardarlo, solo necesita verificar la validez del "certificado" que trae la cookie cada vez, y también puede contener información ligera. Este método suele denominarse tokens.
El proceso del token es el siguiente:
* *"Cómo almacenar tokens de cliente" Como se mencionó en la sección anterior sobre cookies, las cookies no son la única forma en que los clientes almacenan credenciales . Debido a su "apatridia", el período de validez y las restricciones de uso del token están incluidos en el contenido del token. Depende menos de las capacidades de administración de cookies y permite al cliente guardar más libremente. Pero el método principal de las aplicaciones web sigue siendo colocarlas en cookies. Después de todo, no te preocupes demasiado. "Caducidad del token"* *Entonces, ¿cómo controlamos la fecha de vencimiento del token? Muy sencillo. Simplemente junte el "tiempo de caducidad" y los datos y juzgue durante la verificación.
El método de codificación es rico y frugal. * * "base64" * * Como la biblioteca cookie-session-npm en el lado del nodo.
De forma predeterminada, cuando le doy un ID de usuario, lo guarda así:
eyj1c2vyawqiojin0 = aquí está solo la base64 de {"userid": "abb"}. "A prueba de manipulaciones"
Sí, depende, si el token implica permisos confidenciales, tenemos que encontrar una manera de evitar que el token sea manipulado. La solución es firmar el token para identificar si ha sido manipulado. Por ejemplo, en la biblioteca cookie-session-npm se agregan dos configuraciones:
De esta forma, habrá varias configuraciones. sig cookie, donde el valor se calcula a partir de {"userid": "abb"} e iAmSecret utilizando un algoritmo de cifrado, como HMACSHA256 (system.security.encryption) |
Bien, ahora CDD puede falsificar eyj1c2vyawqiojin0 =, pero no puede falsificar el contenido de sig porque no conoce el secreto. * *"JWT"* *Pero el enfoque anterior aumenta la cantidad de cookies y los datos en sí no tienen un formato estandarizado, por lo que nació una introducción al token web JSON: jwt.
Es un esquema maduro de generación de cadenas de tokens, que incluye los datos y firmas que mencionamos anteriormente. ¿Por qué no ves cómo se ve un token JWT?
¿Cómo surgió esta ristra de cosas? Mire la imagen:
Tipo, opciones de algoritmo de cifrado, campos de datos estándar JWT. Puede consultar el nodo RFC 7519-JSON Web Token (JWT), que también tiene una implementación de biblioteca relacionada: express-jwt-npm. koa-jwt-npm.
Token, como guardián de la autoridad, lo más importante es la "seguridad". El token utilizado por la interfaz empresarial para la autenticación se denomina token de acceso. Cuanto más sensible sea la empresa a los permisos, más esperamos que el período de validez del token de acceso sea lo suficientemente corto como para evitar que lo roben. Sin embargo, un período de validez demasiado corto hará que el token de acceso caduque con frecuencia. ¿Qué debo hacer si caduca? Una forma es pedirle al usuario que vuelva a iniciar sesión para obtener un nuevo token, lo que obviamente no es fácil de usar. Debes tener en cuenta que algunos tokens de acceso pueden caducar después de unos minutos. Otra forma es tener otro token, uno que genere específicamente tokens de acceso, llamémoslo token de actualización.
Al utilizar tokens de actualización, el flujo de solicitudes en varios casos se vuelve así:
Si el token de actualización ha caducado, solo puede volver a iniciar sesión.
Sesión y token son conceptos con límites difusos.
Como se mencionó anteriormente, los tokens de actualización también se pueden organizar y mantener en sesiones. En un sentido estricto, generalmente pensamos que la sesión es un esquema de autenticación que "se coloca en una cookie y los datos se almacenan en el servidor", y el token es un esquema de autenticación en el que "el cliente puede almacenarse en cualquier lugar y los datos se almacenan". en la ficha". La comparación entre sesión y token es esencialmente una comparación entre "el cliente guarda cookies/lugares" y "el servidor guarda datos/no guarda datos". * *"El cliente guarda cookies/lugares"* *Guardar cookies es muy conveniente, pero el problema también es obvio:
Guárdelo en otro lugar para resolver el escenario sin cookies, se puede evitar con la cinta manual de; parámetros ataque CSRF. "El servidor guarda datos/no guarda datos"
Ya sabemos que en un sistema de autenticación cliente/servidor bajo un mismo dominio, el cliente lleva unas credenciales que permanecen conectadas durante un periodo de tiempo. Cuando haya más y más líneas de negocios, más sistemas comerciales estarán dispersos bajo diferentes nombres de dominio, lo que requiere la capacidad de "inicio de sesión único, común a todas las líneas", que es el llamado "inicio de sesión único".
Simple, si todos los sistemas comerciales están bajo el mismo nombre de dominio principal, como tieba.baidu.com, wenku.baidu.com, será simple. Puede configurar directamente el nombre de dominio de la cookie en el nombre de dominio principal Baidu.com, que es lo que hace Baidu.
Por ejemplo, una empresa conocida como Didi posee nombres de dominio como didichuxing.com, xiaojukeji.com y didiglobal.com. Este tipo de cookies es completamente inevitable. Sólo cuando se pueda lograr el "inicio de sesión único, una talla única", podrá ser un verdadero inicio de sesión único. En este caso, necesitamos un servicio de autenticación independiente, a menudo llamado SSO. "Proceso completo del sistema A al sistema B, no es necesario iniciar sesión".
* *"Versión completa: considere escenarios de navegador"* *El proceso anterior parece estar bien. De hecho, es suficiente para muchas aplicaciones. Pero es posible que no funcione en el navegador. Mire aquí:
Para los navegadores, ¿cómo guardar los datos devueltos en el dominio SSO para que puedan recuperarse al acceder a A? Los navegadores tienen restricciones estrictas entre dominios y métodos como las cookies y el almacenamiento local tienen restricciones de dominio. Esto requiere que solo A pueda proporcionar la capacidad de almacenar credenciales en el dominio A. En términos generales, así es como lo hacemos:
En la imagen, codificamos con colores el nombre de dominio donde se encuentra actualmente el navegador. Preste atención a los cambios en la descripción del texto gris en la imagen.
Gracias a todos.