lo ideal sería que los dos sitios son subdominios de un dominio común (por ejemplo forum.example.com y rails.example.com), o comparten el mismo dominio (www.example.com.) Uno de los sitios sería el autenticador primario, y establece una cookie (para .example.com en el caso del dominio principal común [observe . antes de example.com] o www.example.com en el caso del dominio compartido, para que ambas aplicaciones puedan acceder a él), donde la cookie contiene:
- la
user ID
- un
salt (valor aleatorio calculado en el momento de inicio de sesión) y
- un
SHA-2 signature calculado sobre el triplete (user ID + salt + a shared secret key), donde la clave secreta compartida es una cadena secreta conocido por bo los sitios.
Cada sitio sería capaz de recuperar la user ID y salt de la cookie, a continuación, utilizar el shared secret key (conocido sólo por las dos aplicaciones) para calcular una SHA-2 signature que debe coincidir con el SHA-2 signature almacenada en la cookie.
Si coincide el SHA-2 signatures, puede asumir que el usuario está autenticado, de lo contrario, obligue al usuario a iniciar sesión de nuevo.
La cookie se debe destruir al cerrar la sesión.
La letra pequeña
Para protegerse contra el robo de sesiones, todas las solicitudes realizadas en los dos sitios debe ser cifrado a través de SSL (usar https). Si esto no es posible, un hash basado en la dirección IP del cliente así como también el tipo de navegador y la versión (User-agent) probablemente deberían calcularse al momento del inicio de sesión y también almacenarse en la cookie. Se debe volver a verificar contra la dirección IP del cliente y el agente de usuario antes de atender cada solicitud. El enfoque basado en hash es la seguridad a través de la oscuridad, y puede ser engañado; además, un usuario que acceda a Internet desde detrás de un conjunto de proxies o use TOR puede ser expulsado por su sistema cada vez que un proxy diferente o un nodo de salida (con una dirección IP diferente) reenvía una solicitud.