Stack Overflow: Support for OpenID Ends on July 1, 2018 | Hacker News Reader

Stack Overflow: Support for OpenID Ends on July 1, 2018

meta.stackexchange.com

145 pointsingve77 comments

I am one of the 13k that is that little red guy. I just migrated my openid provider to a docker container and changed the certificate to LetsEncrypt.

Slashdot removed support, as did shirt woot and deletionpedia. Freecode and gitorious are gone. After this, the only things I'll have left on openid will be pipy (which doesn't seem to work) and openstreetmaps.

I understand why and the technical debt involved, but this still makes me very sad. We're moving in the wrong direction. We're going away from open, federated, distributed standards and back to closed, wall-gardened, proprietary, massive identity providers.

> We're going away from open, federated, distributed standards and back to closed, wall-gardened, proprietary, massive identity providers.

I'm not. I just create an email and password for each site I use. A password manager means that's not a big deal.

EDIT: I meant to say I create an account based on email and password. I don't actually create a separate email address per site.

I create an email for every site. I can recommend it.

Do you do this programmatically? Or with the +suffix@.... trick?

Neither nor. I have my own domain. Every website gets <website>@mydomain. Every email @mydomain gets forwarded to my primary email. As simple as that.

+1. I've been doing this for 20+ years. Every site I register gets a new account following a pattern <prefix><site>@mydomain.com.

Incredibly helpful to track who leaked your email and to whom, better control spammers, etc. Just checked on Have I been Pwned, and I have 30 emails from my domain there [1]. Anecdotally, there's at least another 50-100 email addresses that I get spam regularly, so HIBP is a small subset of all the leaks.

Easy to implement. I use G Suite with Gmail[2], but it works with most other providers.

[1] https://haveibeenpwned.com/

[2] disclaimer: I work for Google, but not on G Suite team, and I pay for the service on my own.

Yeah, the + trick is not that great, because it is quite obvious what your real email is. This way, not so much. One could of course still guess that you are using this trick when they see that your email matches their domain name. If you're paranoid about that, you could of course just use <random string>@yourdomain for every login. And store that in your password manager.

Anything at a custom domain that doesn't look direct to an individual (e.g. not realname@domain.tld) is a big hint to spammers that the owner uses a catch-all and thus any address will get the job done. I suppose you could go with a whitelist for every random address you give out and blacklist the ones that misbehave, but that's a lot of work and, since every company misbhaves these days, including entities like banks, you'll likely miss emails you actually need.

I don't care much about spammers. The filter at FastMail is good enough. What I care about mostly is to make automatically correlating my identity between different websites harder.

> you could of course just use <random string>@yourdomain for every login

You could also use the hash of the domain name with a secret salt value. Then if you somehow lost your login info, you could still figure out what your recovery address was if you still knew the salt.

Nice! Another domain owner here. Never thought to have a sink-all mailbox. Thanks for sharing.

I used to use this trick, but got sick of fighting the bulk spam sent to admin@, postmaster@, etc. the filters got most of it, but damn it was annoying whenever they changed tactics and a small flood would sneak by before being identified by the filters and further spam prevented.

That's why I moved from maintaining my own mail server (with spam filter and activate sync) to a provider. I still own the domain and have a catch-all configured for per-account mail addresses on a subdomain with the mail going to bulk folder on my primary IMAP. The subdomain also prevents the dumbfire admin@... spam.

Only spam I get is on leaked addresses.

Instead of using <service>@, sign-up with <service><secret>@ and forward only the messages that match *<secret>@

Add the email to a virtual address config file.

> We're moving in the wrong direction.

The thing is, too often do people lament the loss of federated/open systems and quickly jump on a blame train spanning the users who "are making the wrong choices by not using the 'obviously better, open systems' and the corporations who 'push their evil walled gardens onto users'".

But few people actually think about what is actually causing these shifts. Users don't usually care about open vs. closed, and seldom care about ideology. They want their shit to work without hassle, to look good, to achieve what they want.

I see so many people blaming users and companies for moving away from IRC, onto systems like Discord and Slack. Why you gotta blame the consumers when they are merely switching to obviously better alternatives? IRC is not a suitable replacement for Discord today, and systems like XMPP and OpenID are massive fucking messes. They don't get used because they're too hard to use. Usability is a feature.

Honestly, I think proprietary solutions win so often because they value pragmatism by nature, whereas open solutions tend to value ideology. Sometimes, you have visionaries at the helm who do value pragmatism and you end up with the best of both worlds. Torvalds is an excellent example: He produces pragmatic, open software and his way, although not "ideologically pure", has done more to promote free software than Stallman ever has.

Not to point fingers; I definitely know there are Stallman-wannabees floating around the site who are in it purely to feel superior to others, and be able to wag their finger and make fun of those using "crass, proprietary software". They don't try to understand why consumers use the proprietary solutions (they can't try, because they refuse to use them). And at the end of the day, the needle hasn't moved.

Anyway, all that to say, we're moving in the wrong direction because too many people cling onto the systems that have obviously lost (openid and IRC) without considering why consumers use oauth2 and slack. It's armchair lamenting.

I have this strange feeling while reading your comment, as if you would respond to the tragedy of the commons with, "Isn't it great! We should get rid of all the commons!"---even though the result would be materially worse.

Open, federated systems are possibly, arguably, better, both in terms of ideology (or alternative, more specific terms like "privacy") and (maybe) technology. But, as you say, users don't care about open/closed, they don't care about ideology, they don't even care about technology. They care about ease of use and appearance.

Open, federated systems will never be as simple as proprietary systems. Further, they'll never attract the money necessary to get even as close as possible in terms of ease of use and appearance. Non-proprietary systems will usually lose out of the gate, not because they're dragging a 100lb anvil of ideology but because the alternatives have a magic tailwind of simpler requirements and more resources. (And that's as pragmatic as you can get, right?)

Note: I'm not a Stallman-wannabe, I'm not wagging fingers (at the moment, on this issue), and I use proprietary solutions all the time. But I also know what I'm trading off.

Serious question: Why is email so successful? Why hasn't Facebook messenger or Slack or WhatsApp or any other siloed messaging service unseated it? Is it just because it was there first and now it's entrenched?

Why can't other services work like email and Matrix and have success? A lot of it just seems like success of marketing to me.

Another thing to consider is that e-mail is actually part of the DNS standard. Of course with SRV records, you could add discovery for any new arbitrary service via DNS, but the fact that it's part of that standard says something to just how old it is.

I think part of it is just the ease of setting up services. You can install new programs on your desktop win/macos and they'll update themselves and all that, but servers are not so easy. There are things that are coming out that make servers more pluggable/lego brick build-able like Sandstorm, and maybe one of those will really take off and make hosted apps something more individuals would be willing to pay for.

E-mail also has its huge share of problems. Setting up your own e-mail server is also super unreliable because of over-aggressive spam filters, as I wrote about here:

http://penguindreams.org/blog/how-google-and-microsoft-made-...

1. Like gmail? Hotmail? Any others?

2. You could argue that many of those others are taking over part of the email use-case, including file transfers.

3. I dunno.

Agree 100% the reality is more poignant when you go out of the tech bubble. Also if those open standards affect product maintainability vs simple integrations with less code, projects will tend to avoid it.

This is also Why complex Piracy/CD Ripping lost steam with services like Spotify/Netflix in countries with big piracy rings. Good user experience trumps ideology.

You seem to misunderstand technical debt [0]. There is no technical debt here. There is a maintenance overhead – as there is with every line of code – which SO no longer wish to support.

I do agree that we are going in the wrong direction, and that we should be building open, federated, distributed protocols/standards. However, OpenID is not a good example of such given its dependencies.

[0] https://en.wikipedia.org/wiki/Technical_debt

> OpenID is not a good example of such given its dependencies.

What is meant by "dependencies" here?

> Of our 9,813,747 accounts around one-tenth of a percent are actively using OpenID

I created an account on SO using an OpenID provider in 2009. In 2014, the provider disappeared and with it, the ability to log into the account. I was never warned about this and have never been able to access that account again.

Since then I only access SO via web searches (didn't create another account). I wonder how many people are in the same situation.

I've always delegated my address to a provider of choice, so as providers fall I've been able to adjust my delegation. That ability to delegate any domain you control (or even different pages on the same domain) to any provider you wanted to use was one of the best features of OpenID, and something that is lost in most of the "OpenID" Connect systems like FB/Google login where provider is locked as soon as you click the button.

OpenID Connect works for users though. "Sign in with Google" is something people understand.

The original OpenID, where my identity was a URL that wasn't a website, and wasn't my email address, was never easy to explain.

OpenID was built for the world where everyone had a blog, so everyone had at least one URL that was a website that they controlled that was also their OpenID. It was easy to explain in that world. That world barely existed, and now is long gone, for better/worse.

Wow, I had almost forgotten about that. Yeah, I never really understood it...

You're probably talking about myOpenID, that shutdown affected quite a few people as far as I remember. You can get back access to the account by contacting SE support in many cases (https://stackoverflow.com/contact).

That was me as well. Thankfully I also had tied a Google account to StackOverflow so it wasn't a big deal, but I replaced MyOpenID with django-openid on my personal site. That package later turned out to be dead when I updated to a modern version of Django so I forked it to make it work.

Which is a lot of work to do nothing at all . . . I just really like the idea of OpenID.

When I was a mod on the site, I know that you could email the dev team or ping a mod to ping the dev team to fix this. They were usually pretty quick about it.

Yes, they combined a couple of accounts (that all belonged to me) with an email or two (and some validation, IIRC).

Having considered this from the start, I linked 3 different auth providers to my Stackoverflow account, and it did help me more than once.

Consider doing this if you only depend on a single Google / FB / other account.

this happened to me too, and I wrote up how I recovered from it, here: https://igor.moomers.org/recovering-openid

it's fairly painless

Nice write up!

I created my SO account via OpenID too, but somehow I am still able to login via email. I don't know, maybe I did something to enable that, but in general there should be no problem using an old OpenID account with SO.

I dodged this only because my openID provider was verisign, then symantec, and I managed to see the warnings that they were sunsetting OpenID service

This isn't a big surprise, if anything it's surprising it lasted as long, but some thoughts/comments:

> The reality is OpenID support has created a ton of complexity in our codebase

I don't doubt this is true but I do find it surprising. I would be interested to see a breakdown of this from a technical perspective. I'm sure it adds complexity, but in the context of the overall complexity of SO I would have expected it to be relatively overshadowed.

> Users have spoken with their actions. You prefer Google, Facebook and Stack Exchange (aka email/PW) based account auth.

No, they haven't. OpenId use in SO has declined for two reasons: (1) providers shutting down and (2) Stack Overflow UI changes to hide the option from users in the login form (making my logins require extra clicks).

> around one-tenth of a percent are actively using OpenID (defined as having visited a site in the past 12 months). If you include all the inactive accounts it is still less than 2.9% of all accounts.

0.01 up to 2.9 is a massive jump and seems to indicate a high active user turnover. I wonder what the user activity retention rates are on SO. What percentage of currently active users are very recent joiners.

It's a little sad, but OpenID implementations ended up being rather one sided. Everyone wanted to be an OpenID identity provider, but fewer wanted to be on the consumer side. For OpenID to succeed that relationship needs to change.

There was simply no benefit for the larger sites to access OpenID as an authentication mechanism. Perhaps the EUs General Data Protection Regulation can change that to some extend for smaller sites that wish to store almost nothing about the users, while still authenticating them.

OpenID was also notoriously difficult to implement

Isn’t OAuth even worse?

Yeah, compared to OAuth is OpenID a piece of cake.

Wouldn't know :)

As I see it, it has been replaced by OAuth, which is created for a different purpose but works just as well for login and authentication.

No, OpenID has been replaced by OpenID Connect, a profile of OAuth 2.0 written to specifically address user sign in.

OAuth 2.0 is an authorization framework, not an authentication protocol. OAuth 2.0 can be used for a lot of cool tasks, one of which is person authentication.

OpenID Connect is a “profile” of OAuth 2.0 specifically designed for attribute release and authentication.

For more info, see our blog: OAuth vs SAML vs OpenID Connect. [1]

[1] https://www.gluu.org/resources/documents/articles/oauth-vs-s...

OpenID Connect is still not in any way comparable with traditional OpenID.

Nobody said it was...

> OpenID has been replaced by OpenID Connect

Replaced != compatible.

Also, "traditional OpenID" is very ambiguous phrasing... are you referring to OpenID 1? OpenID 2? or OpenID Connect?

While we're playing inequality, comparable != compatible.

oops! i've been staring at the screen too long!!

I doubt that. Its just that everyone wanted to use those fancy facebook/google/whatever logins and nobody really cared for the decentralized login concept.

In fact, the few websites which supported OpenID allowed to use custom providers while OAuth mostly limited to handful of social media providers. So OpenID was a way to decentralize the web and prevent password reuse while OAuth is a strategy by large Social Media corporations to increase your dependence on their brand.

In the end they both might be able to authenticate and to prevent password reusage to some extend, but their motivations and implications are very different.

I used a project called phpmyid, some time ago, but it was quite easy to use and allowed me to run my own identity from my server.

And they compensated by finally allowing users to add new email/password authentications to their account. Woo-hoo! I'd originally signed in with Google but I'd much rather have personal per-system logins, and now this is possible.

Huh, I'm one-tenth of one percent.

AMA, I guess.

But yeah, this got me into trouble a couple times. I actually have a /openid URL on my site that redirects to Google, but forgot. This, mixed with accidentally having two accounts (back when Careers was it's own thing) meant some poor SO rep had to do a whole bunch of untangling one day.

I'm glad they're consolidating systems into an easier-to-understand thing. If it had just be email/password from day 1, I don't think I'd have had half the troubles I did by trying to be "future-compliant".

FWIW, I've used OpenID for login on my personal wiki [1] for a few years and haven't had a spam issue [yet].

To forgo the bother of managing being provider or even relayer, I just use a Dreamwidth (the LiveJournal fork) profile [2]. Always interesting using a url as a login. For those who say that's confusing for the masses, there was a method of mapping e-mail address to OpenID profiles. [3]

I was a bit confused as to why OpenID Connect turned out the way it did, moving focus from federated to the closed "Login with Facebook/Twitter/GitHub/Dropbox/Google" thing (if they is Oauth/OIDC based?).

I guess the above could be related - I get no spam because federated OpenID didn't take off, and federated OpenID didn't take off because companies wished to sidestep a future spam problem.

[1] https://wiki.thingsandstuff.org

[2] https://www.dreamwidth.org/openid

[3] https://mashable.com/2008/09/30/openid-email-addres

It's a bit strange that nowhere in the post does SO mention OpenID Connect...

OpenID 1 & 2 have been dead and deprecated for some time...Google deprecated support in 2016.

All domains should move to supporting the latest iteration, OpenID Connect, which, by all indications, looks like it will be stable and relevant for many years to come.

OpenID Connect is stable, sure. But relevant? I'm not aware of any major identity provider or consumer who uses OpenID Connect.

Seriously? How about Google?

https://developers.google.com/identity/protocols/OpenIDConne...

Ah, Stack Exchange (and Overflow) Meta never stops to make me smile : they used a post closed as 'non constructive' as a reference in an official announcement.

> Of our 9,813,747 accounts...

Stack Exchange has less than 10 million registered users? That’s surprisingly low even for Stack Overflow alone. I wonder how many MAUs they get...

~50 monthly visitors. The key here is you don't need an account to get the value. https://stackoverflow.com/company

Tangentially related:

The openid.net website is blocked by some popular web filters as "virus/malware".

Anyone know why?

Which web filters? I can't see any reason why it would be blocked, as I couldn't find any history of malware infection on it and they don't even have ads (so no history of their ad network pushing exploits).

I don't get why OpenID was introduced in the first place then. The point of using an open auth protocol is to not become dependent on monopolies, isn't it? The figures being what they are isn't supportive of this decision when using OpenID is considered a strategic decision. I thought you could use Google at least (but not Fb) as OpenID Connect provider, so wouldn't it make more sense to deprecate support for Google-proprietary login schemes instead?

Also, as remarked on the followup stackexchange discussions, this will make stackexchange login (against Google, Fb) JavaScript-only, won't it?

Could somebody with more know-how clue me in about the state of affairs of OpenID and web auth?

> I don't get why OpenID was introduced in the first place then.

Because the Internet needs standards to work. If all domains implement authentication differently, we do not have an interoperable network.

As is customary, standards must evolve to keep up with requirements. OpenID 1 and 2 weren't built with the idea that smart phones would be in every persons pocket, or Internet connected devices in every home.

The latest iteration of OpenID--OpenID Connect--is essentially Google's playbook for authentication. It's of huge value to the rest of the world.

To put it simply: having your own OpenID Provider at your domain (e.g. idp.example.com) allows you to operate a similar authentication infrastructure as Google.

What does that mean?

- Single sign-on (SSO) across web and mobile applications

- Ability to support a variety of strong authentication mechanisms (a.k.a 2FA), like U2F security keys and OTP mobile apps, in one place for many apps

If all apps and services were to align with OpenID Connect, we would have a truly scalable and interoperable identity layer for the Internet.

But what's the point of OpenID Connect being interoperable, if unlike in OpenID, the providers are statically defined by the site and not dynamically discovered from the user input? If you want to have your own provider for your own sites, then you don't need it to be interoperable.

OpenID Connect defines two important standards: Discovery [1] and Dynamic Registration [2].

All OpenID Providers publish their details at a publicly discoverable (and standard) domain: https://{hostname}/.well-known/openid-configuration.

For instance, you can see our OP meta data here [3].

This provides the foundation for using email as an identifier, i.e. in order to access protected resource at autonomous site, input email at a domain with an OP, and the RP can perform discovery to find where to send the user for authentication, and dynamic registration to register their client (app) with the OP to obtain user information ("claims").

[1] https://openid.net/specs/openid-connect-discovery-1_0.html

[2] https://openid.net/specs/openid-connect-registration-1_0.htm...

[3] https://idp.gluu.org/.well-known/openid-configuration

> For instance, you can see our OP meta data here [3].

Do you e-mails end with @idp.gluu.org? Or how would the RP discover that the domain is not "gluu.org" but "idp.gluu.org"?

no, but using my email adress @gluu.org, you can find the discovery endpoint because its a standard address for domains. For instance, here's Google's OP discovery endpoint:

https://accounts.google.com/.well-known/openid-configuration

How do I find that discovery endpoint, given your email address @gluu.org? https://gluu.org/.well-known/openid-configuration doesn't exist. I don't even know that idp.gluu.org is a thing from your email address.

> All OpenID Providers publish their details at a publicly discoverable (and standard) domain: https://{hostname}/.well-known/openid-configuration.

No, no they don’t. Not by far. Google, for example, doesn’t - and even if they did, it wouldn’t be useful, as they don’t support dynamic client registration either, as they want lock-in. Being able to type in my email address into a generic widget and get the Google auth dialog is specifically what they don’t want.

Facebook has the same issue, as does Yahoo. I don’t think I know of a single implementer of OpenID Discovery and Dynamic Client Registration - the only purpose of OpenID Connect as deployed in the wild is to share development resources, not to create a system where people can type in their email address into a generic widget which works for every OpenID Connect supporting domain off the shelf with no RP-side configuration and get a login form.

Yes they do.

See here:

https://accounts.google.com/.well-known/openid-configuration

And as far as I know, Facebook doesn't support OpenID Connect. They still roll their own custom OAuth2 implementation.

That is, obviously, not on gmail.com. I cannot put in my email address into a generic widget and have that come up - the URL has to be hard-coded into the RP, and the RP additionally has to be configured with client authentication details. This document cannot be autodiscovered from a user identifier as per the spec, and provides absolutely nothing over hard-coding the configuration it contains.

It's nice that the support is there, but are there any sites actually using it? My concern is that default matter - ie, if you make it easier to just support a few fixed servers, that's what will generally happen.

Many sites are doing identifier first authentication, incuding google.

When you login to google, it prompts you for an email address first. If your email is associated with an organization that has configured Google Apps to use their OP for authentication, Google will redirect the user to their home domain based on the email.

I don’t think OpenID connect is the same thing as OpenID

"OpenID" Connect is absolutely not the same thing as OpenID and should never have had OpenID in the name.

Just wait until you hear about Javascript and C#.

Reply on news.ycombinator.com