Mi enfoque designa un dominio como dominio "central" y cualquier otro como dominios "satélite".
Cuando alguien hace clic en un enlace de inicio de sesión (o presenta una cookie de inicio de sesión persistente), el formulario de inicio de sesión envía finalmente sus datos a una URL que está en el dominio central, junto con un elemento de formulario oculto que indica el dominio vino de (solo por conveniencia, por lo que el usuario es redirigido hacia atrás).
Esta página en el dominio central luego establece una cookie de sesión (si el inicio de sesión fue bien) y redirige a cualquier dominio desde el que el usuario inició sesión, con un token especialmente generado en la URL única para esa sesión .
La página en la URL del satélite verifica ese token para ver si corresponde a un token que se generó para una sesión, y si es así, se redirige a sí mismo sin el token y establece una cookie local. Ahora ese dominio satelital también tiene una cookie de sesión. Esta redirección borra el token de la URL, por lo que es poco probable que el usuario o cualquier rastreador grabe la URL que contiene ese token (aunque si lo hicieran, no debería importar, el token puede ser un token de uso único).
Ahora, el usuario tiene una cookie de sesión tanto en el dominio central como en el satélite. Pero, ¿y si visitan otro satélite? Bueno, normalmente, parecerían al satélite como no autenticado.
Sin embargo, a lo largo de mi aplicación, cada vez que un usuario está en una sesión válida, todos los enlaces a páginas en los otros dominios de satélite tienen un? S o & s adjuntados a ellos. Reservo esta cadena de consulta 's' para indicar "verificar con el servidor central porque consideramos que este usuario tiene una sesión". Es decir, no se muestra ningún id. De token o sesión en ninguna página HTML, solo la letra "s" que no puede identificar a alguien.
Una URL que reciba dicha etiqueta de consulta 's', si aún no hay una sesión válida, redirige al dominio central diciendo "¿me puede decir quién es?" poniendo algo en la cadena de consulta.
Cuando el usuario llega al servidor central, si están autenticados allí, el servidor central simplemente recibirá su cookie de sesión. Luego enviará al usuario de vuelta al satélite con otro token de uso único, que el satélite tratará como un satélite después de iniciar sesión (ver arriba). Es decir, el satélite ahora configurará una cookie de sesión en ese dominio y se redireccionará a sí mismo para eliminar el token de la cadena de consulta.
Mi solución funciona sin script o soporte iframe. Requiere '' s 'agregarse a cualquier URL entre dominios donde el usuario aún no tenga una cookie en esa URL. Pensé en una forma de evitar esto: cuando el usuario primero inicia sesión, configura una cadena de redireccionamientos alrededor de cada dominio, configurando una cookie de sesión en cada uno. La única razón por la que no he implementado esto es que sería complicado en el sentido de que necesitaría tener un orden establecido para que estas redirecciones ocurrieran y cuándo detenerse, y evitaría que se expanda más allá de 15 dominios o más (demasiados más y te vuelves peligrosamente cercano al 'límite de redirección' de muchos navegadores y servidores proxy).
Esto es muy similar a oauth2. Usted ha colocado el inicio de sesión automático encima, que es una buena opción si posee todas las aplicaciones. – matthuhiggins
Buena respuesta, pero tengo algunas consideraciones sobre su respuesta: 1) No necesita pasar la url satelital como retorno, puede usar el encabezado HTTP url-referer para esto. 2) Tu token de devolución no es seguro, incluso si se trata de un token de uso único, un atacante puede interceptar la devolución de devolución y usar el token fuera de la aplicación de llamada antes de que se complete la validación, el enfoque correcto es generar un código de seguridad en esclavo y validar el token con este código en el dominio central, el token es público pero es inútil para el atacante sin el código de seguridad. –
3) si utiliza un servidor de estado completo (información de usuario almacenada en la memoria o base de datos), no necesita cambiar la URL para verificar primero el inicio de sesión, porque el atacante puede cambiar la URL en el lado del cliente, el cheque debe hacerse en cada solicitud, incluso sin la consulta en url. Entonces, cuando un usuario solicita una url segura, comprueba si el usuario se autenticó (información de usuario en la memoria) y si la autenticación sigue siendo válida (después de x horas de inicio de sesión), de lo contrario, lo redirecciona al servidor de inicio de sesión nuevamente. –