Hacker News Reader

Comment by slooonz | Hacker News Reader

Apparently, still not going in the direction of OpenID where the end-user specifies (in an open-ended way) his authorization provider instead of choosing from a handful of big well-known providers (Google/Facebook/Github) handpicked by the relying party.

Not surprised, but still disappointed.

View on HN

OpenID and OAuth are different things though? Sure, OpenID Connect is built on top of OAuth 2.0, but OAuth 2.0 is a general authorization solution. You couldn’t just interact with arbitrary APIs so there’s really no point in creating a bring-your-own-API-server thing.

It's different things though, or?

OAuth is about getting access to something, and usually part of that is proving to some authorization server that you are you (ie what OpenID is about), no?

Do you mean you'd like OAuth to tackle the "you are you" part as well?

GP has written authorisation but they must mean identification, because only a resource owner can perform authorisation, not some random external service.

authN = autheNtication (identity / "who are you")

authZ = authoriZation (access / "what are you allowed to do")

Also, in general

OAuth => think authZ

OIDC => think authN

Yep.

And auth0 ("auth Zero, not letter o") is a company / service that offers both authN and authZ.

That's probably like 30% of the uses of OAuth (e.g. granting Azure Pipelines access to your GitHub repos). 70% is just outsourcing identity and authentication (log in with Google / Facebook / etc.) In those cases the only data they access is your email, profile image, etc.

As a website developer I would definitely appreciate something like OpenID but actually usable/popular. Having to implement a ton of "log in with"s sucks, as does implementing email based login.

100% agreed. I would love to find a language or library that makes one or both of them trivial.

> Having to implement a ton of "log in with"s sucks, as does implementing email based login.

This is kind of auth0's--but also most security token service things--raison d'etre: your app trusts just one authority and supports just one protocol, shunting any unauthenticated users to it, letting it handle the transaction with trusted identity providers.

Indeed. I miss OpenID, and the promise it had.

Same here. I even setup an openid provider using my domain - was great!

Me too! I just checked and I still have the headers in my html. Should probably remove them :)

OpenID Connect is a superset of OAuth 2.0 so I find this an odd comparison. Assumedly there'll be an authN OIDC OAuth 3.0 protocol too.

I was excited about OpenID around 2010. I wasn't aware it was still possible to use; most of the services I've looked at either support OIDC (built on top of OAuth) or SAML.

How could the specification support letting the end-user pick their authorization provider? Should the RC suggest the AS instead of the RS doing so?

The user could enter an email-like identity, where the domain part determines the provider.

Reply on news.ycombinator.com