Hacker News Reader

Comment by splitbrain | Hacker News Reader

From what I understand this handles only authentication and provides tokens that may be used for additional (undefined APIs).

What bugs me about this (and all the oAuth implementations out there) is that you never just want authentication. You also want to know things about the user (username, name, email, avatar, etc) - but to get this you have to implement a plethora of APIs for the various services, because they are all different. I wish fetching profile info would be part of the standard.

View on HN

Fetching profile information isn’t part of it because it lets people do it in the way that they feel most comfortable. Conventionally, though, you can pull the useful bits by fetching their h-card https://indieweb.org/h-card as noted here https://indieweb.org/IndieAuth#Where_do_I_get_user_informati...

https://v2.jacky.wtf/post/482a99db-4650-48df-910a-b162b828d2...

For OAuth, this is part of the standard OpenID Connect[0], which extends OAuth 2.0. I'm not sure how IndieAith handles this.

[0]: https://openid.net/specs/openid-connect-core-1_0.html#UserIn...

How about... asking them for it?

Yeah would it kill you to pick up the phone every once in a while? You can't beat the personal touch!

I don't get why you are being downvoted. It's a legitimate strategy. Register with oauth (or whatever) and then fill in the blanks (nickname, etc.)

That's basically what we have to do as a SAML service provider. Most SAML identity providers don't release identifying information—out of apathy or ignorance usually, not because of privacy concerns—so we take whatever (hopefully persistent) identifier we're given, re-identify the user at registration time, and call it a day.

I've never seen a SAML IdP that can't release that stuff as claims when configured properly. Are you having trouble getting people to do that when you use SAML?

Oh sure, a SAML IdP or OIDC OP _can_ release all kinds of info, but they generally don't if our experience with InCommon and eduGAIN IdPs is any guide. We even made sure we complied with REFEDS R&S (https://refeds.org/category/research-and-scholarship/).

You just described OpenID Connect.

Which is basically dead? No?

OpenID Connect, aka. 'OIDC', is widely deployed. It's a compatible extension on top of OAuth 2.0, the latter of which was often used to provide third-party apps some delegated access to users' data at some data silo. This all coincided with the proliferation of HTTP-native APIs inspired by the easiest-to-implement tenets of REST. The payload of OIDC and OAuth 2.0 can be carried with in HTTP headers, which is a good fit for these APIs and simplifies implementation.

OIDC is used by some branded 'sign-in' buttons like 'Sign-in with Google' [1], and the new 'Sign in with Apple' feature is a close copy of the OIDC, if not yet directly conformant and compatible [2].

[1] https://developers.google.com/identity/protocols/OpenIDConne... [2] https://openid.net/2019/06/27/open-letter-from-the-openid-fo...

But no one supports using an arbitrary domain, like your own hosted OpenID Connect.

The old "OpenID" is dead; the new "OpenID Connect" (OIDC) is an identity layer on top of OAuth 2, and is very much not-dead.

Reply on news.ycombinator.com