7

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.

Improve this question
8
  • Note that Stack Exchange has a public API that lets you do almost anything you can do on SE using a browser.
    – user8397947
    Commented Feb 11, 2017 at 0:09
  • What is this "SSO" you speak of?
    – This_is_NOT_a_forum
    Commented Feb 11, 2017 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
    Commented Feb 11, 2017 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
    Commented Feb 11, 2017 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
    Commented Feb 11, 2017 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 Mod
    Commented Feb 11, 2017 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
    Commented Feb 11, 2017 at 20:41
  • so I guess they don't want to make it public then?
    – kks21199
    Commented Feb 13, 2017 at 21:25

1 Answer 1

Reset to default
15

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.

Improve this answer
13
  • 1
    Great to see that 1px image hacks are still going strong!
    – curiousdannii
    Commented May 4, 2018 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
    Commented May 7, 2018 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 StaffMod
    Commented May 7, 2018 at 15:39
  • 1
    @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
    Commented May 7, 2018 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.sstatic.net/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.sstatic.net/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 StaffMod
    Commented May 7, 2018 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
    Commented May 8, 2018 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
    Commented May 8, 2018 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 StaffMod
    Commented May 9, 2018 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
    Commented May 10, 2018 at 11:15
  • To set the cross-domain cookie by an AJAX request, you can use Jquery with crossDomain: true, xhrFields: { withCredentials: true }, and in your PHP script you need to set those headers: header('Access-Control-Allow-Origin: https://www.example.com'); header('Access-Control-Allow-Credentials: true');. Then the cookie will be set successfully.
    – Avatar
    Commented Jun 15, 2020 at 10:59
  • 1
    @AdamLear in new versions of browsers, third-party cookies disabled by default. How you solve this problem? I have same mechanism of sso on my sites already 8 years, and now it stop working =)
    – demon101
    Commented Jun 16, 2020 at 12:58
  • Correct, since June 2020 it does not work anymore, also not for Stackoverflow/Stackexchange: stackoverflow.com/q/62578201/1066234
    – Avatar
    Commented Jun 26, 2020 at 7:45
  • 2
    @demon101 We haven't made any changes and I'm not aware of any plans for that at the moment. For us it's always been a "best effort" kind of a thing - logging in once on an SE site at least gets you into all the other SE sites, and we do our best to link up sessions if you then also log in on SO or SU or another site with its own domain.
    – Adam Lear StaffMod
    Commented Jun 26, 2020 at 22:36

You must log in to answer this question.

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