Autenticación y autorización

Como todos sabemos, los servidores web no tienen estado, lo que significa que el servidor no sabe qué hizo el usuario en la última solicitud y las solicitudes son independientes entre sí. La información del cliente solo proviene de información pública incluida en cada solicitud o guardada por el propio servidor, y puede ser utilizada por todas las solicitudes. Por lo tanto, para rastrear la información de estado solicitada por el usuario, como el historial del carrito de compras en línea, surgieron las Cookies.

Cuando el servidor responde a la solicitud del cliente, envía una cookie al cliente. Esta cookie registra cierta información en el servidor. El cliente porta esta cookie en solicitudes posteriores y el servidor puede determinar el contexto de la solicitud en función de esta cookie.

La aparición de cookies es un medio de transición de un estado sin estado a un estado.

Tome el inicio de sesión como ejemplo. El usuario ingresa el nombre de la cuenta y la contraseña y envía una solicitud al servidor. El servidor genera una cookie y la envía al navegador. El navegador guarda la cookie en un archivo de texto en un directorio en formato k-v y envía la cookie al servidor la próxima vez que solicita el mismo sitio web. El servidor verifica si la cookie recibida es consistente con la cookie del servidor; de lo contrario, la verificación falla. Esta es la idea original.

img src=' (nombre de dominio 1) y c.d.e.f.com.cn (nombre de dominio 2). El nombre de dominio 2 quiere leer la cookie del nombre de dominio 1. ¿Qué dominios se pueden declarar para el nombre de dominio 1? La respuesta es e.ffcom.cn o .f.com.cn. El navegador no puede aceptar cookies cuyo nombre de dominio sea .com.cn, porque si el nombre de dominio de la cookie se puede configurar como un sufijo, será una guerra de cañones.

Si Set-Coo está configurado para el nombre de dominio 1

kie: mykey=myvalue1;domain=e.f.com.cn;path='/'

Dominio nombre 2 configuración Set-Cookie: mykey=myvalue2;domain=e.f.com.cn;path='/'

Entonces el valor de mykey en este dominio se sobrescribirá como myvalue2. Es fácil de entender. En el mismo dominio, Cookie La mykey es única. Por lo general, debemos configurar el dominio y la ruta correctos para reducir la transmisión de datos innecesaria y ahorrar ancho de banda.

Con el aumento del uso interactivo de la Web, las restricciones de tamaño de las cookies y las restricciones del navegador en cuanto a la cantidad de cookies almacenadas, debemos necesitar un espacio más potente para almacenar una gran cantidad de información del usuario, como quién es nuestro sitio web. Después de iniciar sesión, quién ha agregado productos a su carrito de compras, etc., el servidor necesita almacenar decenas de millones o más de información de usuarios y las cookies obviamente no son adecuadas. ¿Qué hacer?

¿Dónde se almacena la información del usuario? ¿Se puede almacenar directamente en el servidor?

Si existe en el servidor, 1. Esto supone una gran sobrecarga para el servidor, lo que limita seriamente la capacidad de expansión del servidor. 2. Suponga que el servidor web tiene carga equilibrada y el usuario usuario1 inicia sesión en el sistema a través de la máquina A. Luego, si la siguiente solicitud se reenvía a otra máquina B, la información del usuario no se almacena en la máquina B, por lo que no se puede encontrar. sessionId, por lo que sessionId no debe almacenarse en el servidor. En este momento, apareció redis / Memcached para resolver este problema. Pueden entenderse simplemente como una base de datos de caché.

Cuando almacenamos de forma centralizada el sessionId en un servidor de caché independiente, todas las máquinas van a este sistema de caché para obtener información del usuario y autenticación basada en el sessionId. Entonces el problema estará resuelto.

Según su principio de funcionamiento, ¿ha encontrado algún problema con este método? Eso aumenta la posibilidad de que falle el inicio de sesión único. Si la máquina responsable de la sesión cuelga, todo el inicio de sesión también colgará. Pero, en general, en los proyectos, la máquina responsable de la sesión también es un grupo de varias máquinas para equilibrar la carga y aumentar la confiabilidad.

Pensando:

Si se reinicia el servidor, ¿se perderá la información del usuario?

Los servidores de caché como Redis también tienen clústeres. Si se reinicia un determinado servicio, buscará información del usuario en otros servidores en ejecución. ¿Qué pasa si todos los servidores fallan al mismo tiempo? La estrategia de respuesta general es que la información del usuario almacenada en la memoria se descargará periódicamente en el disco duro del host para conservar los datos. Incluso si se pierde, solo se perderán los datos del usuario dentro de los pocos minutos posteriores al reinicio.

Limitaciones de las sesiones de cookies

Al depender de las cookies, los usuarios pueden desactivar las cookies en el navegador.

No admite aplicaciones compatibles entre terminales, etc.

p>

El sistema empresarial solicita constantemente al servidor de caché que busque información del usuario, lo que aumenta la sobrecarga de memoria y ejerce una presión excesiva sobre el servidor.

El servidor tiene estado si no hay un servidor de caché, se expande. será muy difícil y deberá realizarse mediante una copia loca de los ID de sesión en varios servidores

Existe la posibilidad de que falle el inicio de sesión único

Inicio de sesión único (Inicio de sesión único), denominado SSO. Con el desarrollo de las empresas, un sistema grande puede contener n múltiples subsistemas. Cuando se operan diferentes sistemas, los usuarios deben iniciar sesión varias veces, lo cual es muy problemático para resolver este problema. Solo es necesario iniciar sesión una vez para acceder a otros sistemas de uso de confianza mutua.

Dijimos antes que el inicio de sesión único se basa en compartir cookies con el dominio superior, que se puede dividir en los siguientes tres tipos según las diferentes situaciones.

Bajo el mismo sitio;

El sistema está bajo el mismo nombre de dominio de nivel superior;

Cada subsistema pertenece a un nombre de dominio de nivel superior diferente

General En este caso, una empresa tiene un nombre de dominio de nivel superior. Como se mencionó anteriormente, el inicio de sesión único en el mismo sitio y el mismo dominio de nivel superior utiliza la función de compartir dominio de nivel superior de cookies. Creo que todos ya comprenden este proceso y no lo repetirán nuevamente. ¿Pero qué pasa si es un dominio diferente? Las cookies no se comparten entre diferentes dominios. ¿Qué debo hacer?

Aquí vamos a hablar del proceso CAS (Servicio de Autenticación Central), que es el proceso estándar para el inicio de sesión único. Utiliza un sistema separado específicamente para la autenticación, que a continuación se denomina sistema SSO.

El proceso es en realidad el mismo que el modo de sesión de cookies. El inicio de sesión único significa que cada subsistema tiene un conjunto completo de modos de sesión de cookies, más un conjunto de modos de sesión de cookies.

Los usuarios acceden al sistema a y saltan al sistema SSO cuando necesitan iniciar sesión. Después de pasar la autenticación de cuenta y contraseña en el sistema SSO, el servidor SSO guarda la sesión, genera un ID de sesión y lo devuelve a el navegador SSO, el navegador escribe la cookie en el dominio SSO y genera un ST, transporta el ST y lo pasa al sistema a. El sistema a utiliza este ST para solicitar la verificación del sistema SSO. servidor del sistema a voluntad El estado de inicio de sesión se escribe en la sesión y se coloca la cookie en el dominio a del sistema. Más adelante, cuando el sistema a realice la verificación de inicio de sesión, será la autenticación bajo el mismo dominio.

En este momento, el usuario accede al sistema b. Cuando salta a SSO y se prepara para iniciar sesión, descubre que SSO ya ha iniciado sesión. Luego, SSO genera un ST y lo lleva al sistema b. El sistema b usa este ST para solicitar. El sistema SSO realiza la verificación. Una vez que la verificación es exitosa, el servidor del sistema b escribe el estado de inicio de sesión en la sesión y configura la cookie en el dominio del sistema b. Se puede ver que en este proceso, el sistema b ya no necesita iniciar sesión.

Con respecto a "saltar a SSO y prepararme para iniciar sesión, descubrí que SSO ya inició sesión". Dé una idea, es decir, cuando el sistema b salta al sistema SSO, déjelo saltar del sistema a, lleve la información de la sesión del sistema a al SSO y luego redirija nuevamente al sistema b.

Para Oauth2, puede leer "Cuatro formas de OAuth 2.0" de Ruan Yifeng.

Ya hemos analizado las limitaciones de Cookie-session. ¿Existe una solución más exhaustiva? Dado que la existencia de un sistema de autenticación SSO aumenta la posibilidad de un único punto de falla, ¿simplemente no deberíamos necesitarlo? Esta es la idea de descentralización, es decir, eliminar el servidor de caché utilizado para almacenar y verificar la información del usuario, y verificarla en sus respectivos sistemas de otra manera. En pocas palabras, el método de implementación consiste en cifrar toda la información de la sesión en una cookie y enviarla al navegador, utilizando la potencia informática de la CPU a cambio de espacio.

El servidor no guarda el ID de sesión. Después de que el usuario inicia sesión en el sistema, el servidor le emite un token. La próxima vez que el usuario solicite acceder al servidor a través de Http nuevamente, se pasa el token. el encabezado Http o la URL. Tráigalo para su verificación. Para evitar que otros lo falsifiquen, podemos agregar una clave que solo nosotros conocemos a los datos, crear una firma y enviar los datos y la firma juntos como un token. De esta manera, no necesitamos guardar el token, porque el token enviado al usuario ya contiene la información del usuario. Cuando el usuario vuelve a solicitarlo, utilizo el mismo algoritmo y clave para cifrar los datos en el token. Si el resultado cifrado es coherente con la firma del token, entonces podemos autenticar y obtener la información del usuario.

Para el servidor, esto solo es responsable de generar tokens y luego verificarlos. No es necesario un servidor de caché adicional para almacenar una gran cantidad de sesiones, solo cuando aumenta el número de visitas. Es necesario abordar los requisitos de acceso. Simplemente expanda la capacidad de un servidor grande, lo cual es más económico que expandir todo el servidor del centro de usuarios.

Si alguien manipuló la información del usuario, pero como se desconoce la clave, la firma en el token y la firma calculada por el cliente después de la manipulación definitivamente serán inconsistentes y la autenticación fallará. por lo que no hay necesidad de preocuparse por cuestiones de seguridad.

En cuanto a la puntualidad del token, así es como se hace. Cuando inicias sesión por primera vez, se genera un token basado en la contraseña de la cuenta. Para cada solicitud posterior, el servidor actualiza el. marca de tiempo y envía un nuevo token, y el cliente reemplaza el token original.

Cerrar sesión en modo jwt es en realidad un error de inicio de sesión falso, porque es solo una ilusión causada al borrar el token en el lado del navegador. Si usa el token anterior, aún puede iniciar sesión correctamente siempre que. no ha caducado

La seguridad depende de la clave, una vez que la clave está expuesta

Los datos generados por el cifrado son relativamente largos y ocupan relativamente más tráfico

No depende de cookies y se puede utilizar en terminales y programas Uso, compatible con dispositivos móviles

En comparación con el modo de sesión de cookies sin inicio de sesión único, es muy fácil de expandir

El servidor mantiene características sin estado y no necesita almacenar información del usuario en el servidor o en la sesión

Para el inicio de sesión único, el modo de envío continuo de solicitudes de verificación al sitio SSO ahorra muchas solicitudes relacionadas. preguntas y respuestas: