Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

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?

View on HN

> 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