10

Once upon a time, stackauth.com was used for global authentication, for the API, etc.
And the StackAuth home page still states:

This is a domain for centralized services across the entire Stack Exchange network.

In addition to site enumeration for the StackExchange API, StackAuth also serves as the storage domain for our global authentication scheme.

Due to the unreliability of third-party cookies in modern browsers, our scheme uses HTML 5's localStorage to store login credentials under the StackAuth domain...

  1. I'm pretty sure that the API last used stackauth.com with version 1.1 (Deprecated in 2012).
  2. Although I remain logged-in to many Stack Exchange sites, plus the API, plus chat, plus SEDE; when I visit https://stackauth.com/, it shows nothing stored in localStorage.

So,
Is stackauth.com still in use?
If so, when/how? If not, when did it stop?


PS: I use openid.stackexchange.com to authenticate on the SE network.

Improve this question
3
  • Pretty sure it's still used for cross-domain login, but I don't deal with login that much anymore so I'll defer to someone who does.
    – Shog9 Mod
    Commented Jun 13, 2017 at 23:11
  • Thanks, @Shog9. You mean cross network, like with Facebook, etc., credentials? The openid.stackexchange.com is already cross domain to 6 other domains (and countess subdomains).
    – Awesome Poodles
    Commented Jun 13, 2017 at 23:17
  • 1
    @AwesomePoodles No, cross-domain as in stackoverflow.com, stackexchange.com, serverfault.com, etc. We have 6 or 7 of these second level domains all told. The credential you're using to log in doesn't matter. What does matter is how we set the cookie that identifies you as logged in. Used to set it with the help of StackAuth. Now we don't.
    – Adam Lear StaffMod
    Commented Jun 13, 2017 at 23:22

1 Answer 1

Reset to default
9

Ah yeah, that write-up should be updated since we no longer do any of that. We stopped when universal login was rolled out, so... January 2016 or thereabouts.

The last remaining auth-related feature on StackAuth is its participation in the OAuth flows (that is, logging in with Google or Facebook). Routes at stackauth.com serve as callback URLs in the OAuth-using apps registered with FB and Google. This allows us to only have one app registered per provider, since the callback domain typically needs to be provided in the app config and we have a lot of domains.

Improve this answer
2
  • Hey Adam, why did you drop that old method ? What were the downsides of it?
    – CodyBugstein
    Commented May 2, 2018 at 1:49
  • @CodyBugstein Keeping auth bits on a separate domain wasn't great UX - it was flaky depending on connectivity issues, and required a page refresh because we wouldn't know if a person was logged in before we had a chance to do a roundtrip to stackauth. We just use a cookie per second-level domain now.
    – Adam Lear StaffMod
    Commented May 3, 2018 at 21:49

You must log in to answer this question.

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