Cross Domain Login - How to log a user in automatically when transferred from one domain to another
Solution 1:
Single sign-on (SSO) is conceptually pretty simple.
- User hits
domain1.com
. -
domain1.com
sees there's no session cookie. -
domain1.com
redirects tosso.com
-
sso.com
presents login page, and take credentials -
sso.com
sets session cookie for the user -
sso.com
then redirects back todomain1
to a special url (likedomain1.com/ssologin
) - the
ssologin
URL contains a parameter that is basically "signed" by thesso.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 followsdomain1
and redirects tosso.com
-
sso.com
already has a cookie for the user, so does not present the login page -
sso.com
redirects back todomain2.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.
Solution 2:
If someone were able to play man in the middle and grab that hash, would they be able to steal the cross domain transfer? Obviously it needs to be generated and sent to the client prior to them needing to use it. So say for instance:
I'm playing man in the middle spying on Jack.
Jack accesses domain1.com
which causes a hash to be prepared and sent to him so that when he accesses domain2.com
he can send that hash as authentication.
As he accesses domain1.com
, his request comes through me, you return the page, I grab the hash and let him carry on.
I access domain2.com
using the hash, you've now let me into domain2.com
and deleted the hash.
He's none the wiser until he attempts to login to domain2.com
and is told that his credentials are no longer valid.
How do you overcome that?
Solution 3:
There wouldn't be any point using SSL for the cross-domain login unless you use SSL for the entire session. It is just as easy to steal a session cookie as it is to use a hash in an url. What is the point in hiding the hash in SSL if the rest of the session is insecure.
The method given at the top is pretty much the standard method. Whether you choose to use secure protocols is another matter entirely, but it would be pointless to only encrypt part of the session.