Idealmente i tuoi due siti sono sottodomini di un dominio comune (ad esempio forum.example.com e rails.example.com), o condividono lo stesso dominio (www.example.com.) uno dei siti sarebbe l'autenticatore principale e impostare un cookie (per .example.com nel caso del dominio padre comune [notare lo . prima di example.com] o www.example.com nel caso del dominio condiviso, in modo che entrambe le applicazioni possano accedervi), dove il cookie contiene:
- il
user ID
- un
salt (valore casuale calcolato al momento del login) e
- un
SHA-2 signature calcolato sulla tripletta (user ID + salt + un shared secret key), in cui la chiave segreta condivisa è una stringa segreta conosciuto da bo i siti
Ogni sito sarà in grado di recuperare il user ID e salt dal cookie, quindi utilizzare il shared secret key (conosciuto solo dalle due applicazioni) per calcolare un SHA-2 signature che deve corrispondere al SHA-2 signature memorizzati nel cookie.
Se lo SHA-2 signatures corrisponde, è possibile assumere che l'utente sia autenticato, altrimenti obbligare l'utente ad accedere nuovamente.
Il cookie deve essere eliminato durante la disconnessione.
La piccola stampa
Per la protezione contro il dirottamento di sessione, tutte le richieste fatte nel corso dei due siti devono essere crittografati su SSL (utilizzare https). Se questo non è possibile, un hash in base all'indirizzo IP del client così come il tipo di browser e la versione (User-agent) dovrebbero probabilmente essere calcolati al momento del login e anche essere memorizzati nel cookie. Dovrebbe essere ricontrollato con l'indirizzo IP e l'agente utente del cliente prima di servire ogni richiesta. L'approccio basato su hash è la sicurezza attraverso l'oscurità e può essere ingannato; inoltre, un utente che accede a Internet da un pool di proxy o che utilizza TOR può essere espulso dal sistema ogni volta che un diverso proxy o nodo di uscita (con un diverso indirizzo IP) inoltra una richiesta.