Tabla de contenido
Prefacio
En el sistema B / S, la función de inicio de sesión generalmente se implementa en base a cookies . Cuando el usuario inicia sesión correctamente, el estado de inicio de sesión generalmente se registra en la sesión , o se emite un token al usuario . De cualquier manera, se debe guardar cierta información (ID de sesión o token) en el cliente, y el cliente es obligatorio para llevarlos en cada solicitud posterior.
En tal escenario, el uso de cookies es sin duda el más conveniente. Por lo tanto, generalmente guardamos el ID de sesión o Token en la Cookie. Cuando el servidor recibe la solicitud, verificará la información en la Cookie para determinar si el usuario es conectado.
El inicio de sesión único ( SSO ) significa que en varios sistemas de aplicaciones bajo la misma plataforma de cuenta, los usuarios solo necesitan iniciar sesión una vez para acceder a todos los sistemas de aplicaciones de confianza mutua.
Por ejemplo, Baidu Tieba y Baidu Maps son dos sistemas de aplicación diferentes bajo Baidu. Si un usuario inicia sesión en Baidu Tieba, no necesita iniciar sesión de nuevo cuando accede a Baidu Maps, entonces significa que hay una brecha entre Baidu Tieba y Baidu Maps. Se realiza el inicio de sesión único.
La esencia del inicio de sesión único es compartir el estado de inicio de sesión entre varios sistemas de aplicaciones . Si el estado de inicio de sesión del usuario se registra en la sesión, para darse cuenta del estado de inicio de sesión compartido, la sesión debe compartirse primero. Por ejemplo, la sesión se puede serializar a Redis , de modo que múltiples sistemas de aplicaciones puedan compartir el mismo Redis y leer Redis directamente para obtener Session.
Por supuesto, esto por sí solo no es suficiente, porque los diferentes sistemas de aplicación tienen diferentes nombres de dominio. Aunque la sesión se comparte, debido a que la ID de sesión a menudo se almacena en la cookie del navegador, existen restricciones de alcance y no se pueden pasar a través de nombres de dominio , es decir Supongamos que cuando el usuario inicia sesión en app1.com, el ID de sesión solo se incluirá automáticamente en el encabezado de la solicitud cuando el navegador visite app1.com, y cuando el navegador visite app2.com, el ID de sesión no se transferirá. . La clave para lograr el inicio de sesión único es cómo compartir el ID de sesión (o Token) en varios dominios.
Método de implementación 1: Cookie de dominio principal
Antes de comprender la implementación específica, hablemos sobre el alcance de Cookie.
El alcance de la cookie está determinado por el atributo de dominio y el atributo de ruta . El valor válido del atributo de dominio es el nombre de dominio / dirección IP del dominio actual o su dominio principal. En Tomcat, el atributo de dominio tiene como valor predeterminado el nombre de dominio / dirección IP del dominio actual. El valor válido del atributo de ruta es la ruta que comienza con "/". En Tomcat, el atributo de ruta toma por defecto la ruta de contexto de la aplicación web actual.
Si el atributo de dominio de la cookie se establece en el dominio principal del dominio actual, entonces se considera una cookie de dominio principal. La cookie tiene una característica, es decir, la cookie del dominio principal es compartida por el dominio secundario , es decir, el dominio secundario heredará automáticamente la cookie del dominio principal .
Con esta función de Cookie, no es difícil pensar que no es suficiente guardar el ID de sesión (o Token) en el dominio principal. Sí, solo necesitamos la propiedad de dominio de Cookie para el nombre de dominio principal (dominio principal), mientras que el atributo de ruta de la cookie se establece en la ruta raíz, de modo que todas las aplicaciones de subdominio tengan acceso a la cookie de .
Sin embargo, esto requiere que el nombre de dominio del sistema de aplicación se establezca bajo un nombre de dominio principal común, como tieba.baidu.com y map.baidu.com, ambos establecidos bajo el nombre de dominio principal de baidu.com. luego pueden pasar estas formas para lograr el inicio de sesión único.
Resumen: esta implementación es relativamente simple, pero no admite nombres de dominio primarios cruzados.
Método de realización 2: Centro de certificación
Podemos implementar un centro de certificación, que es un servicio web independiente que es específicamente responsable de procesar las solicitudes de inicio de sesión .
El usuario inicia sesión en el centro de autenticación. Una vez que el inicio de sesión es exitoso, el centro de autenticación registra el estado de inicio de sesión del usuario y escribe el token en la cookie . (Tenga en cuenta que esta cookie pertenece al centro de certificación y el sistema de aplicación no puede acceder a ella).
El sistema de la aplicación comprueba si hay un Token en la solicitud actual, si no es así, significa que el usuario no ha iniciado sesión en el sistema actual, y luego la página se redirige al centro de autenticación. Dado que esta operación traerá automáticamente la cookie del centro de certificación, el centro de certificación puede saber si el usuario ha iniciado sesión de acuerdo con la cookie.
Si el centro de autenticación encuentra que el usuario no ha iniciado sesión, volverá a la página de inicio de sesión y esperará a que el usuario inicie sesión. Si descubre que el usuario ya ha iniciado sesión, no permitirá que vuelva a iniciar sesión. pero volverá a la URL de destino y generará una antes de que el token de salto se empalme detrás de la URL de destino y se envíe de vuelta al sistema de aplicación de destino.
Una vez que el sistema de solicitud obtiene el Token, también debe confirmar la legalidad del Token con el centro de certificación para evitar que los usuarios lo falsifiquen. Una vez que la confirmación es correcta, el sistema de la aplicación registra el estado de inicio de sesión del usuario, escribe el Token en la Cookie y luego libera la visita. (Tenga en cuenta que esta cookie se encuentra en el sistema de aplicación actual y no puede ser accedida por otros sistemas de aplicación). Cuando el usuario accede al sistema de aplicación actual nuevamente, traerá automáticamente este Token. El sistema de aplicación verifica el Token y encuentra que el usuario está iniciado sesión, por lo que no ¿Qué pasó con el centro de certificación?
Por cierto, aquí están las implementaciones de código abierto de dos centros de certificación:
Apereo CAS es un sistema de inicio de sesión único de nivel empresarial, donde CAS significa "Servicio de autenticación central". Originalmente fue un proyecto del Laboratorio de la Universidad de Yale, luego fue transferido a la organización JASIG, el proyecto pasó a llamarse JASIG CAS, posteriormente la organización se incorporó a la Fundación Apereo y posteriormente el proyecto pasó a llamarse Apereo CAS.
XXL-SSO es un sistema simple de inicio de sesión único, desarrollado personalmente por el ingeniero de Dianping Xu Xueli. El código es relativamente simple y no hay control de seguridad, por lo que no se recomienda su uso directo en el proyecto. Se enumera aquí para solo referencia.
Resumen: este tipo de implementación es relativamente complicado, admite dominios cruzados y tiene una buena escalabilidad. Es una práctica estándar para el inicio de sesión único.
Método de implementación 3: Dominio cruzado de LocalStorage
Anteriormente, dijimos que la clave para el inicio de sesión único es cómo compartir el ID de sesión (o Token) entre varios dominios.
La cookie de dominio principal es una buena solución, pero no admite dominios cruzados. Entonces, ¿existen trucos para hacer que las cookies pasen de un dominio a otro?
Desafortunadamente, los navegadores tienen restricciones entre dominios cada vez más estrictas sobre las cookies. El navegador Chrome también agrega un atributo SameSite a las cookies, que casi prohíbe la transmisión de cookies para solicitudes de dominio cruzado (excepto hipervínculos), y solo cuando se utiliza el protocolo HTTPs se puede permitir en solicitudes de dominio cruzado AJAX Aceptar cookies del servidor.
Sin embargo, en el caso de que el front-end y el back-end estén separados, las cookies son completamente innecesarias. Podemos optar por guardar la ID de sesión (o Token) en el LocalStorage del navegador, para que el front-end tome la iniciativa de guardar el LocalStorage cada vez que se envía una solicitud al back-end, los datos se pasan al servidor. Todos estos están controlados por el front-end. Todo lo que debe hacer el back-end es pasar el ID de sesión (o Token) en el cuerpo de la respuesta al front-end después de que el usuario inicie sesión correctamente.
En tal escenario, el inicio de sesión único se puede implementar en la interfaz. Una vez que el front-end obtiene el ID de sesión (o Token), además de escribirlo en su propio LocalStorage, también se puede escribir en LocalStorage en varios otros dominios por medios especiales.
El código clave es el siguiente:
// 获取 token
var token = result.data.token;
// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
iframe.remove();
}, 6000);
// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
localStorage.setItem('token', event.data)
}, false);
El front-end usa iframe + postMessage () para escribir el mismo Token en LocalStorage bajo múltiples dominios. Cada vez que el front-end envía una solicitud al back-end, leerá activamente el Token de LocalStorage y lo llevará en la solicitud. El mismo token es compartido por varios dominios.
Resumen: Esta implementación está completamente controlada por el front-end, casi sin participación de back-end, y también admite dominios cruzados.
Suplemento: clasificación de nombres de dominio
Desde un punto de vista profesional (de acuerdo con la definición en "Computer Network"), .com y .cn son nombres de dominio de primer nivel (también llamados nombres de dominio de nivel superior), .com.cn y baidu.com son de segundo nivel. nombres de dominio de nivel y sina.com. Cn y tieba.baidu.com son nombres de dominio de tercer nivel, y así sucesivamente, los nombres de dominio de nivel N son subdominios directos de los nombres de dominio de nivel N-1.
Desde el punto de vista del usuario, el nombre de dominio principal que admite la presentación independiente generalmente se denomina nombre de dominio de primer nivel. Por ejemplo, baidu.com y sina.com.cn se pueden llamar el nombre de dominio de primer nivel y el nombre de subdominio establecido bajo el nombre de dominio principal Se denomina nombre de dominio de segundo nivel, como tieba.baidu.com es un nombre de dominio de segundo nivel.
Para evitar ambigüedades, utilizaré el término "nombre de dominio principal" en lugar de "nombre de dominio principal".