I am really wondering why the SE community of sites is each under it's own login system --> to me it looks like it passes the session data to each but I am not sure.

The reason why I am asking is that I run a series of internal websites at my company. Right now they are all their own entity and use an SSO service. It is the same user population. I am wondering what are the plus and minuses of having the users go through the sign up process that they have on SE. I can see from a management process it would help me with rights based stuff but not sure each user would want to go through that for a small site.

Note: The question used SE as an example because that is one way I was proposing a solution to my UX. I would like answers on my problem not SE's problem.

  • My best guess would be so that users accumulate separate Rep for each site. I believe sessions are maintained for sites you are signed up for (i.e. I'm a member of Graphicdesign.se UX.se & stackoverflow, so I stay logged in on all 3, but when I go to poweruser.se I'm not signed in) Commented Jul 16, 2014 at 20:47
  • 1
    @AdamMThompson But all of this could be contained in a super table or nested table in the database. I'm not sure why they make people do this and I am not sure if the internal people will hunt me down if they have to "Click OK" for every new tool to register.
    – blankip
    Commented Jul 16, 2014 at 20:49
  • I would agree with you, it's not really the best UX. What would your proposed workflow look like? Commented Jul 16, 2014 at 20:54
  • 1
    @AdamMThompson - Currently my users don't even see anything once they log onto SSO. If they are on a site and haven't logged on to SSO then they are automatically redirected there. The problem with this is that maintaining different user abilities on sites gets a little tricky.
    – blankip
    Commented Jul 16, 2014 at 21:00
  • 1
    @JohnDeters - been throwing that around for a while. I currently hae 6-7 SSO sites and 10-11 sites that are on their own - that I need to in some way migrate to SSO. It is complex because I migrate new users from LDAP feed onto user tables nightly. If you are on user table you get at least basic rights in all SSO sites... It would be a bit of work for some of my previous sites with layered perms to be migrated. So an alternative is just have them hit an OK button and secretly they are sending names, empl #, email... through session variables.
    – blankip
    Commented Jul 17, 2014 at 13:21

3 Answers 3


Here are two reasons I've been told when I've asked other team members (Full disclosure: I work for Stack Exchange.)

  1. Initially when the network was much smaller 3-4 years ago, the team had some issues with cross-domain authorization. You can read more about it here.
  2. Another reason someone else hinted at: just because you created an account on UX.SE doesn't mean you'll want one on Math.SE or History.SE or Bicycles.SE. Our communities have very specific focuses and automatically registering everyone for every site will create a lot of empty accounts which helps no one. By making people opt into every community they want to join, we know that every registered user has at least some interest in the community's subject matter. This is important. If you get a lot of "accounts" but no one is ever doing anything, it starts to feel a bit like a ghost town (and IMO a bit disingenuous).

Now I know the team has talked about ways of making the overall experience better. But I don't know of anything in the immediate future.

  • 1
    For your point 2, why not just list users who have been active on a particular subsite rather than all users? Commented Jul 18, 2014 at 10:35
  • I have some sites that are quite small and may contain 20 pages of training content on a product. Do you feel a user would be OK with seeing a pre-screen so they can click OK to join?
    – blankip
    Commented Jul 18, 2014 at 15:55
  • @Hynes, The concerns of Point 2 is non existent. There's nothing stopping the "account" from being hidden until the user click "Activate account on this sub SE site" button.
    – Pacerier
    Commented Nov 8, 2015 at 2:19
  • @Pacerier I'm not saying I agree with the reasons fully. There definitely different ways you could go about solving point #2. These are the two reasons that were given to me though when I asked around internally.
    – Hynes
    Commented Nov 8, 2015 at 11:56

I think the main reason they do it this way is that if you never use a particular site in their network, it would be strange to show information about you in that site. For instance, you can search users of sites like this and see their information. If having a SE account meant you had an account for each of their sites and someone searched for you on one you've never used and found information about you, then that just wouldn't make sense.

In theory, anyways.

To answer your question, when you're dealing with internal sites for a company, SSO is a fantastic user experience. Unless it's some kind of opt-in program, it doesn't make much sense to have them sign-up for each site. I work at a company with a similar situation. We have sites all over the place for all kinds of things. Some use SSO, some have their own logins. Needless to say, my experience has been much better on the sites with SSO (the sign on experience anyway).

My recommendation: SSO is the way to go.

  • 1
    Couldn't they just not list users with zero hits on the site or at least zero comments/answers/questions?
    – blankip
    Commented Jul 16, 2014 at 22:40
  • Of course. But as Hynes mentions in another answer, it would also be a waste of space from an account creation standpoint. And finally, since it's been around for a while, they started off having people create account for each one. Decentralizing it now would be a massive undertaking. Not to mention it would complicate the logic of allowing users who don't have an SE account. I think the system they use right now is pretty great for what these sites are. Commented Jul 17, 2014 at 4:33
  • @SethGunnells, "Waste of space"? It's not a waste of space because the users are already created in the umbrella stackexchange.com site. Besides the "space" you are talking about is simply one table with integers doing the linking. That's hardly anything in the grand scheme of things. The concerns of "strange to show information about you in that site" is also non existent. See ux.stackexchange.com/questions/61488/… for explanation.
    – Pacerier
    Commented Nov 8, 2015 at 2:19

For an internal website I think you should go with SSO. You are logged in as an employee and should access everything as an employee.

For an external website I dislike SSO. The best example for me is Google. I have a company account to access my agenda and docs. But I also have a personal account for Google+ and another personal account for Youtube. Simply because I want things separated. But I constantly had to sign-out and in when I switched sites. Now I need to use two separate browsers just to be able to listen to music on Youtube while I want to check my agenda.

At StackExchange I have an option. I can either use a "one-click" sign-up to combine the accounts are choose to be somebody else. Perhaps I'm a programmer at work, but at night I like to take erotic pictures and get advice on photography. I definitely want separate accounts..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.