5 ms·

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

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.

jalcine 7y ago
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 https://indieweb.org/h-card as noted here https://indieweb.org/IndieAuth#Where_do_I_get_user_information_from.3F https://indieweb.org/IndieAuth#Where_do_I_get_user_informati... https://v2.jacky.wtf/post/482a99db-4650-48df-910a-b162b828d265 https://v2.jacky.wtf/post/482a99db-4650-48df-910a-b162b828d2...
pvorb 7y ago
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#UserInfo https://openid.net/specs/openid-connect-core-1_0.html#UserIn...
libeclipse 7y ago
How about... asking them for it?
- iamnotacrook 7y ago
  Yeah would it kill you to pick up the phone every once in a while? You can't beat the personal touch!
- wukerplank 7y ago
  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.)
  - xenophonf 7y ago
    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.
    - eropple 7y ago
      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?
      - xenophonf 7y ago
        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/ https://refeds.org/category/research-and-scholarship/).
andyroid 7y ago
You just described OpenID Connect.
- Bombthecat 7y ago
  Which is basically dead? No?
  - niftich 7y ago
    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/OpenIDConnect https://developers.google.com/identity/protocols/OpenIDConne... [2] https://openid.net/2019/06/27/open-letter-from-the-openid-foundation-to-apple-regarding-sign-in-with-apple/ https://openid.net/2019/06/27/open-letter-from-the-openid-fo...
    - djsumdog 7y ago
      But no one supports using an arbitrary domain, like your own hosted OpenID Connect.
  - LukeShu 7y ago
    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.

jalcine 7y ago

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 https://indieweb.org/h-card as noted here https://indieweb.org/IndieAuth#Where_do_I_get_user_information_from.3F https://indieweb.org/IndieAuth#Where_do_I_get_user_informati... https://v2.jacky.wtf/post/482a99db-4650-48df-910a-b162b828d265 https://v2.jacky.wtf/post/482a99db-4650-48df-910a-b162b828d2...

pvorb 7y ago

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#UserInfo https://openid.net/specs/openid-connect-core-1_0.html#UserIn...

libeclipse 7y ago

How about... asking them for it?

iamnotacrook 7y ago
Yeah would it kill you to pick up the phone every once in a while? You can't beat the personal touch!
wukerplank 7y ago
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.)
- xenophonf 7y ago
  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.
  - eropple 7y ago
    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?
    - xenophonf 7y ago
      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/ https://refeds.org/category/research-and-scholarship/).

andyroid 7y ago

You just described OpenID Connect.

Bombthecat 7y ago
Which is basically dead? No?
- niftich 7y ago
  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/OpenIDConnect https://developers.google.com/identity/protocols/OpenIDConne... [2] https://openid.net/2019/06/27/open-letter-from-the-openid-foundation-to-apple-regarding-sign-in-with-apple/ https://openid.net/2019/06/27/open-letter-from-the-openid-fo...
  - djsumdog 7y ago
    But no one supports using an arbitrary domain, like your own hosted OpenID Connect.
- LukeShu 7y ago
  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.