This is impossible. Cookies are unique to each domain, and one domain cannot read another domain s cookies.

I think the answer comes a little late, but maybe I can help someone.

You can have a cookie / localStorage in an intermediate domain connected to the home page using an iframe

1) Login The login form in any of your domains deposits the identification token in a cookie on sso.domain.com by an event (postMessage) 2) Verification domain1 and domain2 include a iframe pointing to sso.domain.com, which reads the token and notifies the home page

To simplify development, we have released recently a cross domain SSO with JWT at https://github.com/Aralink/ssojwt

There is a simple solution without using an sso server, but not with 1 common cookie, as we know that cookie s are not shared between domains.

When the user authenticates on site-a.com, you set a cookie on site-a.com domain. Then on site-b.com, you link a dynamic javascript from site-a.com, generated by server side script (php, etc) who has access to the created cookie, and then copy the same cookie on site-b.com on the client-side using js. Now both sites have the same cookie, without the need of asking the user to re-login.

You may encrypt/encode the cookie value using a method that both site-a and site-b knows how to decode, so that site-b will be able to validate his cookie copy. Use a common shared secret that without it will be impossible to encode or decode.

You see that on the 1st page load of site-b.com, the cookie is not present, therefore if you see necessary, you may want to do a page reload after setting the cookie.

I have done something similar. There is a PHP application where the user logs in, the system contact a web service and then the service checks the user s credentials on the Active Directory. When the user is authenticated, his PHP session is stored in the DB. Another web application can read the PHP session from the cookies and uery a web service in the PHP applicaiton, the PHP application check the session in the database and return the user id. In this way I have a SSO using SOA.

Do not rely on the user id stored in the browser, is a security error, at least encrypt the id.

The best solution would be to put the login form and session storage in the same application, then this application can provide services to other applications.

And use HTTPS for the kind of infomation exchange.

The cookies can be read only if the belongs to the same domain, for instance:

intranet.example.com crm.example.com example.com/erp

You can access cookies across subdomains, but I do not think using browser cookies is a great solution. You really don t need a "SSO server" to implement a single sign-on. It is fairly easy to come up with a payload that both applications recognize. I have seen custom SSO solutions that transmit the payload using XML over HTTPS.

Here is a solution (which will hopefully get heavily scrutinized by security gurus on here):

Have each domain store user data in a similar cookie, and when a user want to jump from one domain to another without authenticating themselves on the new domain, provide a "jumplink" with an encrypted token in the query string. The new domain would decrypt the cookie, and figure out who the user is, then issue them a new cookie for that domain. You would want the "jumplink" to have a very short expiration date, so I would not generate them right into the page, but generate links to a "jumplink" generator and re-director.

This might not be necessary, but the receiving page for the "jumplink" could make a web service call back to the originating domain, to verify the authenticity of the encrypted token and the whether it s expired.

I think this solution would be susceptible to man-in-the-middle attacks (not sure if it would be more so than other auth mechanisms which are currently popular), but you could incorporate a client MAC address and IP address into the encrypted token for extra security.