Cross Domain Login - How to login a user automatic

Question

We offer a number of online services. We are required to develop a system which provides a quick/simple experience for users if they are transferred from one service (on domain1.com) to another service (on domain2.com).

Is there a safe and secure way to automatically login a user automatically once he has been transferred to the new service?

Yell at me if the solution below is completely insecure/wrong.

We were considering a system similar to that provided by a number of online services for password recovery - they are emailed a link with a unique hash which expires, that allows them to change their password.

The domain1.com would generate a unique hash and store it in a database with the hash linked to a user along with an expire datetime field.

The user will be transferred to domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com would next make a request to domain1.com with the hash to get the information about the user. domain1.com would then remove the hash from the database. domain2.com would log the user in and set cookie etc.

Could something based on OpenID or OAuth achieve the same results?

Answer 1

What about SEO? It looks like every request before succesfull login is redirected to other domain and back. I would tell that this is very ugly. What headers should you send? 301 to SSO and then back 301 to original page? So search bot is "requested" to change his index for that page twice?

Answer 2

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.

Answer 3

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?

Answer 4

This is a good solution. Here are two points to consider:

You use the term "hash", but it's not clear what data you'll hash. Instead, use a "nonce": a large (128-bit) number generated by a cryptographic quality RNG.

Also, you didn't specify this, but communications between the user and both domains, and between the domains themselves, must be secure. Use SSL to authenticate the servers and to keep the nonce confidential.

Answer 5

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.