Cross Domain Login – How to log a user in automatically when transferred from one domain to another

Single sign-on (SSO) is conceptually pretty simple.

• User hits domain1.com.
• domain1.com sees there’s no session cookie.
• domain1.com redirects to sso.com
• sso.com presents login page, and take credentials
• sso.com sets session cookie for the user
• sso.com then redirects back to domain1 to a special url (like domain1.com/ssologin)
• the ssologin URL contains a parameter that is basically “signed” by the sso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key.
• domain1.com takes the encrypted token, decrypts it, uses the new login id to log in the user.
• domain1 sets the session cookie for the user.

Now, the next case.

• User hits domain2.com, which follows domain1 and redirects to sso.com
• sso.com already has a cookie for the user, so does not present the login page
• sso.com redirects back to domain2.com with the encrypted information
• domain2.com logs in the user.

That’s the fundamentals of how this works. You can make it more robust, more feature rich (for example, this is SSOn, but not SSOff, user can “log out” of domain1, but still be logged in to domain2). You can use public keys for signing credentials, you can have requests to transfer more information (like authorization rights, etc) from the SSO server. You can have more intimate integration, such as the domains routinely checking that the user still has rights from the SSO server.

But the cookie handshake via the browser using redirects is the key foundation upon which all of these SSO solutions are based.