Inicio de sesión de dominios cruzados: cómo iniciar sesión automáticamente cuando se transfiere de un dominio a otro

Question

Ofrecemos una serie de servicios en línea. Estamos obligados a desarrollar un sistema que proporcione una experiencia rápida/simple para los usuarios si se transfieren desde un servicio (en domain1.com) a otro servicio (en domain2.com).

¿Existe una forma segura de iniciar sesión automáticamente en un usuario una vez que ha sido transferido al nuevo servicio?

Gríteme si la solución a continuación es completamente insegura/incorrecta.

Estábamos considerando un sistema similar al proporcionado por una serie de servicios en línea para la recuperación de contraseñas: se les envía un enlace por correo electrónico con un hash único que expira, que les permite cambiar su contraseña.

El domain1.com generaría un hash único y lo almacenaría en una base de datos con el hash vinculado a un usuario junto con un campo de fecha y hora de caducidad.

El usuario será transferida a domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com sería el próximo hacer una petición a domain1.com con el hash para obtener la información sobre el usuario. domain1.com eliminaría el hash de la base de datos. domain2.com sería iniciar sesión el usuario y establecer cookies, etc.

¿Podría algo basado en OpenID u OAuth lograr los mismos resultados?

Answer 1

Si alguien fuera capaz de jugar al hombre en el medio y agarrar ese hash, ¿sería capaz de robar la transferencia de dominio cruzado? Obviamente, debe generarse y enviarse al cliente antes de que necesite usarlo. Así que digamos por ejemplo:

Estoy jugando al hombre en el medio espiando a Jack. Jack accede al domain1.com, lo que hace que se prepare y se le envíe un hash para que cuando tenga acceso al domain2.com pueda enviar ese hash como autenticación. Al acceder al domain1.com, su solicitud me llega, usted devuelve la página, agarro el hash y lo dejo continuar. Acceder al domain2.com usando el hash, ahora me has dejado en domain2.com y he eliminado el hash. No sabe nada hasta que intenta iniciar sesión en domain2.com y se le informa que sus credenciales ya no son válidas.

¿Cómo superar eso?

Answer 2

Esta es una buena solución. Aquí hay dos puntos a tener en cuenta:

Usted usa el término "hash", pero no está claro qué datos usará. En su lugar, use un "nonce": un número grande (128 bits) generado por un RNG de calidad criptográfica.

Además, no especificó esto, pero las comunicaciones entre el usuario y ambos dominios, y entre los dominios en sí, deben ser seguras. Use SSL para autenticar los servidores y mantener la privacidad confidencial.

Answer 3

El inicio de sesión único (SSO) es conceptualmente muy simple.

• El usuario acierte domain1.com.
• domain1.com ve que no hay ninguna cookie de sesión.
• domain1.com redirige a sso.com
• sso.com presenta la página de inicio de sesión, y tomar las credenciales
• sso.com conjuntos cookie de sesión para el usuario
• sso.com continuación, vuelve a dirigir de nuevo a domain1 a una URL especial (como domain1.com/ssologin)
• la ssologin La URL contiene un parámetro que básicamente está "firmado" por el sso.com. Podría ser tan simple como una base64 de encriptación del loginid usando una clave secreta compartida.
• domain1.com toma el token cifrado, lo descifra, utiliza el nuevo ID de inicio de sesión para iniciar sesión en el usuario.
• domain1 establece la cookie de sesión para el usuario.

Ahora, el siguiente caso.

• golpea usuario domain2.com, que sigue domain1 y redirige a sso.com
• sso.com ya tiene una cookie para el usuario, por lo que no presenta la página de inicio de sesión
• sso.com vuelve a dirigir de nuevo a domain2.com con la información cifrada
• domain2.com registra en el usuario.

Esa es la base de cómo funciona esto. Puede hacerlo más robusto, con más funciones (por ejemplo, SSOn, pero no SSOff, el usuario puede "cerrar la sesión" de domain1, pero aún debe iniciar sesión en domain2). Puede usar claves públicas para firmar credenciales, puede tener solicitudes para transferir más información (como derechos de autorización, etc.) desde el servidor SSO. Puede tener una integración más íntima, como los dominios que comprueban rutinariamente que el usuario todavía tiene derechos del servidor SSO.

Pero el cookie handshake a través del navegador utilizando redireccionamientos es la base clave en la que se basan todas estas soluciones SSO.

Answer 4

¿Qué hay de SEO? Parece que todas las solicitudes antes del inicio de sesión satisfactorio se redirigen a otro dominio y viceversa. Yo diría que esto es muy feo. ¿Qué encabezados debe enviar? 301 a SSO y luego 301 a la página original? Entonces, ¿el bot de búsqueda es "solicitado" para cambiar su índice para esa página dos veces?

Answer 5

No tendría sentido utilizar SSL para el inicio de sesión entre dominios a menos que use SSL para toda la sesión. Es tan fácil robar una cookie de sesión como usar un hash en una url. ¿Cuál es el sentido de ocultar el hash en SSL si el resto de la sesión no es seguro?

El método dado en la parte superior es más o menos el método estándar. Si elige usar protocolos seguros es otro asunto completamente diferente, pero sería inútil cifrar solo parte de la sesión.