Ideally your two sites are subdomains of a common domain (e.g. forum.example.com and rails.example.com), or share the same domain (www.example.com.) One of the sites would be the primary authenticator, and set a cookie (for .example.com in the case of the common parent domain [notice the . before example.com] or www.example.com in the case of the shared domain, so that both applications can access it), where the cookie contains:
- the
user ID
- a
salt (random value calculated at login time), and
- a
SHA-2 signature computed over the triplet (user ID + salt + a shared secret key), where the shared secret key is a secret string known by both sites.
Each site would be able to retrieve the user ID and salt from the cookie, then use the shared secret key (known only by the two applications) to calculate a SHA-2 signature that must match the SHA-2 signature stored in the cookie.
If the SHA-2 signatures match then you can assume that the user is authenticated, otherwise force the user to log in again.
The cookie must be destroyed when logging off.
The small print
To protect against session hijacking, all requests made over the two sites should be encrypted over SSL (use https.) If this is not possible, a hash based on the client's IP address as well as browser type and version (User-agent) should probably be calculated at login time and also be stored in the cookie. It should be re-checked against the client's IP address and user agent before serving each request. The hash-based approach is security through obscurity, and can be fooled; moreover, a user accessing the internet from behind a pool of proxies or using TOR may be kicked out by your system every time a different proxy or exit node (with a different IP address) forwards a request.
