I am interested in knowing how the current SSO works on the Stack Exchange network. The answer by Kevin here doesn't seem to be in place any more as I can't find anything in the localstorage of stackauth.com.

The updated answer of universal login doesn't exactly explain how the system works. I am looking forward on upgrading a few of my web applications with a universal login. The furthest I have got is to have them redirect to a master domain to check if they are logged in and return a key with POST (given that all of them share one database which is just for storing the key). But this requires the user to be redirected to the master login (when the session starts on a specific application) or the user has to click on the login button manually.

I not looking for any code or anything. Just looking for the logic behind it so I can implement it.

  • What is this "SSO" you speak of? – Peter Mortensen Feb 11 '17 at 8:30
  • 1
    @PeterMortensen: Single sign-on, a generic term for a centralized login system that is reused by multiple discrete sites. – Nathan Tuggy Feb 11 '17 at 9:23
  • @dorukayhan I am not looking to use Stack Exchange's system. I am trying to build one which is nearly identical to the universal login of Stack Exchange. – kks21199 Feb 11 '17 at 10:13
  • @PeterMortensen SSO as in the universal login of Stack Exchange which logs you into all the other site once you login into one of the site. – kks21199 Feb 11 '17 at 10:14
  • Why don't you have a look at Central Authentication Service? It's implementation is open source and supports a much wider range of protocols, clients and scenario's then the closed source solution from SE. The mechanisms between CAS and universal login wouldn't differ much except that the SE one can leverage the fact that they have control over all components involved, making some integrations easier but those integrations and its implementation details are probably never applicable outside of the SE context. – rene Feb 11 '17 at 10:57
  • @rene I saw the CAS workflow and it seems nearly as same as the idea I had. But that still doesn't explain to me how I could achieve it without ever redirecting the user to stackauth. And also when there is no cookie or session present in stackauth. (Given that stackauth is the master login). – kks21199 Feb 11 '17 at 20:41
  • so I guess they don't want to make it public then? – kks21199 Feb 13 '17 at 21:25

Whoops, missed this question when it was first posted... I assume/hope you no longer need this answer a whole year later, but I figured I'd write up the details for posterity.

We do our own session management, not using the stuff built into ASP.NET, so I'm gonna leave those bits out. How you track who a user is is up to you. I'm also gonna leave out the changes made recently to support additional security for Stack Overflow for Teams.

When you come to one of our sites anonymously and log in, we look up the network account that matches the provided credentials and issue you a first-party cookie on the second-level domain you're on (e.g. stackoverflow.com, stackexchange.com, etc).

From there, we have to tell the other domains we have (six or seven in total at this time, if I recall right) that you have logged in. If we were Google or a similar entity with a ton of data centers everywhere, we'd probably just redirect you through all of them and set cookies that way, but... we are not. So we do this via an AJAX request for a 1px transparent image. The request includes a generated token and nonce that are verified on the other end. When that request comes back, it carries with it a third-party cookie for the domain it was sent to.

So, on any given login, we will create several session records on our end for your account, one on each domain. They are linked together by a "group identifier", so that when you log out, all of them are dropped at the same time. This identifier is also used to avoid auto-expiring sessions on domains that weren't visited recently enough when another active session with the same id is present.

When you visit a given Q&A site, we find your account and use that to find your user profile on that site if you are a member of that community, or show you a customized topbar that includes network-wide things like the inbox and achievements even if you don't.

This obviously doesn't work when the user has third-party cookies disabled, but in our case, it still gets most users 99% of the way there (since stackexchange.com covers the majority of our sites). In those cases, if/when you go to log in on a domain you weren't able to get a cookie for, that new session will get the same group identifier as the one you already have on whatever domain you first logged into. That way the sessions can still be kept in sync during logouts.

And that's about it.

  • 1
    Great to see that 1px image hacks are still going strong! – curiousdannii May 4 '18 at 1:07
  • I don't understand the part about how a new site (i.e. askubuntu.com) knows that I previously logged in to another one, (i.e. stackoverflow.com). How does askubuntu.com see any of the session cookies saved by stackoverflow which is a totally separate domain? – CodyBugstein May 7 '18 at 5:29
  • @CodyBugstein It doesn't see those cookies, no. But if your browser allows third-party cookies, when you logged in on Stack Overflow, we sent a request to askubuntu.com that sets a cookie for askubuntu.com as well. – Adam Lear May 7 '18 at 15:39
  • @AdamLear one domain can set a cookie for another domain? I thought the browser keeps cookies separated by domain to prevent cookie stealing. Are you sure? – CodyBugstein May 7 '18 at 16:15
  • @CodyBugstein I am very sure. I implemented this. :) But, a domain isn't reading cookies for another domain. That would, indeed, be stealing. Let's look at the network flow: after you log in on SO, it's like this: i.stack.imgur.com/rtfzT.png - a request per other domain we have. One of those went to askubuntu.com. Here's what came back as a response: i.stack.imgur.com/1R06x.png. askubuntu.com can set a cookie for itself. But, the request did originate on stackoverflow.com, so your browser will prevent the cookie from being set unless third-party cookies are allowed. – Adam Lear May 7 '18 at 17:17
  • Ok that is really interesting. I did not know that a script can set a cookie on a domain other than the one currently being visited. Thank you very much! – CodyBugstein May 8 '18 at 0:21
  • @AdamLear in the screenshot you sent me, the auth token is included in the GET request for unviersal.gif. Isn't that a bad idea? Doesn't that mean anybody along the way could capture the auth token? – CodyBugstein May 8 '18 at 0:37
  • @CodyBugstein The requests all happen over HTTPS, so outside of something extra malicious going on, interception shouldn't be possible. The token/nonce are also expired after one use, so capturing it for reuse later doesn't do anything. – Adam Lear May 9 '18 at 21:46
  • @AdamLear Thanks for the answer :) I went on redirecting users to an authentication site when they click log in. But I think I will implement this idea soon when I have time and test it out. – kks21199 May 10 '18 at 11:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .