7 ms·

IndieAuth – A federated login protocol using one's own domain name

• splitbrain 7y ago
  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?
      • 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.
      • 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.
• sirius87 7y ago
  Anyone know how this compares to Keycloak? Aside: I can't count the no. of times I've referred to Aaron Parecki's OAuth2 Simplified page. EDIT: I guess Keycloak's federation options are limited to LDAP or AD but can be extended with some effort?
  • zaarn 7y ago
    OIDC, which Keycloak Supports, is a tad more versatile than IndieAuth. In my experience, IndieAuth is quite a complicated dance to perform compared to OAuth2, especially since in OIDC, JWT tokens are fairly established to enable apps to get user data. KC's tokens can get you quite a lot of insight and data about a user if you want, or nothing if necessary. IndieAuth uses HTML scraping for that.
    • sirius87 7y ago
      Useful...Thanks!
    • pvorb 7y ago
      Just to clarify: OIDC = OpenID Connect, which doesn't have much to do with the old OpenID but is based on OAuth 2.0.
      • zaarn 7y ago
        OIDC is wonderfull and I have no idea why OpenID put their name on it. "OAuth2 Auto-Configuration" would have done it.
        • pvorb 7y ago
          Yes, absolutely. If it was called something like "OAuth 2 Auto-Configuration and Identity", it would have caused less confusion.
• bullen 7y ago
  I only use single serving server salt hashing for authorization and identification. It requires two requests but it's secure for login and most importantly it's simple enough to implement in javascript. client --- server salt? -> -> generate salt hash(pass+salt) <- <- salt -"- -> -> verify hash done <- <- auth
  • icebraining 7y ago
    You re-hash the client's hash on the server as part of the verification, no?
    • bullen 7y ago
      Yes, the server also knows the "pass" (can be salted hash if you wish, I use hash(pass+name) but it doesn't change the usefulness of this simple auth) and verifies the hash by re-hashing and comparing. Edit: Sad that most people misses the forest for all the trees, should have called pass secr. instead.
      • SomeHacker44 7y ago
        Does this not allow the server credentials to be stolen and then used to log in as you?
        • kingludite 7y ago
          As a bonus you get to try all the passwords on popular websites.
      • zaarn 7y ago
        Congrats, you have been proposed for this years "Plaintext Password Award", the trophy that every industry professional despises but somehow many still manage to obtain one!
      • buildzr 7y ago
• raxxorrax 7y ago
  Nice idea. Wouldn't want to authenticate with my domain for most services though. But for others why not use stuff that already identifies you.
  • jamietanna 7y ago
    Out of interest, why would you prefer not to use your domain? Privacy concerns?
    • raxxorrax 7y ago
      Yes, mainly. I vastly prefer pseudonymity/anonymity on the net and would only reveal my real identity for services that explicitly require it. For shipping, banking, etc.
      • jamietanna 7y ago
        I guess in that case, given it's just a URL you could use ie an autogenerated URL from Netlify or an S3 bucket etc. It doesn't necessarily have to be linked back to your identity
      • floatboth 7y ago
        How is a domain not a pseudonym? With WHOIS Privacy + not even providing your full accurate identity to ICANN in private either :)
      • southerntofu 7y ago
        Well a domain name is usually pseudonymous, although some registrars require some forms of official identification (for legal reasons). Many individuals & organizations hand out domains for free on their zone. That's the case with eu.org or netlib.re for example (among MANY others). Any sysadmin can - and should - run a name server with a simple web application to let other users register domains. See for example https://github.com/KaneRoot/dnsmanager https://github.com/KaneRoot/dnsmanager So domain name-based authentication can bring as much pseudonymity as e-mail based authentication. The difference is owning your name (as prescribed by the indieweb approach) allows you to choose your host for services (including selfhosting for your personal identity), whereas the traditional "identity provider" approach means you're dependant on that provider till the end of times. Of course, we could argue that by owning a name in a zone, your dns provider could just wipe your zone. Although not very likely (ISP-level DNS blocking is more common than actually "seizing" domain names), theses cases are addressed by so-called "nomadic identity" protocols such as ZOT (currently implemented by Hubzilla) which rely on public-key cryptography to die different names/identities together. Then, there's always the possibility of domain names outside of the DNS. A domain name is simply dots linking machine names together, where the DNS is the usual tree-based implementation. But many other protocols provide domain names, the most common being the tor onion services (.onion domain names). So i'll admit actual pseudonymity on the internet remains a research topic, but there's notable progress all the time. Personally, i think we should have a separate domain name / blog / mail for each and every one of our online identities.
• robtherobber 7y ago
  Silly question: what's the difference between IndieAuth, Auth0, 10Duke, Citrix and others when it comes to security, please?
  • aquabeagle 7y ago
    IndieAuth is an open protocol, the others are companies with proprietary products.
    • robtherobber 7y ago
      Thanks!
• djsumdog 7y ago
  I ran the older OpenID protocol for years, but over time, everyone stopped supporting OpenID. Stackoverflow was the last big provider that dropped it entirely. Sure we have OpenID Connect (which is OAuth2 based) and this project mentioned both OpenID/OIDConnect and how it expands on it, but the problem is getting people to allow support on their websites. I think the only places we may see support are newer Fediverse servers like Mastodon, Pleroma, Pixelfed, et. al. Here's my previous article on OpenID: https://penguindreams.org/blog/the-decline-of-openid/ https://penguindreams.org/blog/the-decline-of-openid/
• EGreg 7y ago
  Hey all. Yes using DNS is straightforward to do verified claims like this as well. They require a website to return a public key to anyone who asks. And if the website generates a claim signed by its corresponding private key, then presumably (if they kept that key safe) you can trust that the signing party meant to endorse some claim. A user’s identity is actually the sum total of verified claims about them, from other parties. Those parties, in turn, have identities. With DNS, they are public identities provided by nameservers. The nameservers have identities via being issued IP numbers. Many of these identities also contain routing information for how to actually get a request routed to a specific server program running on the internet (or a relay/hub that will deliver the message to a client who will eg decrypt it). With Javascript, we can take advantage of DNS in an even more straightforward way. Simply use postMessage to an iframe running on the user’s personal app domain. The origin in the browser is guaranteed by https, DNS and IP. The trusted computing base is the OS and browser. You can do much more than authentication with it. I would say that we do NOT actually neeed DNS though. For example, the domain inside the iframe can be intercepted by a cordova application, and represent the LOCAL CLIENT ON YOUR PHONE. No servers needed at all. You can provide your personal data to those peers who need it, without having a “public” identity. Your identity still consists of verified claims by other entities, but in this case the entity is the app running on your phone(s), not a website running on servers. Sure, it didn’t register a “real” domain name with the federated DNS system - and sure, it didn’t get a certificate for the https with the federated “certificate authority” PKI system - but you have previously communicated the public key to your friends in a trusted side channel, and can always prove it is still you via an interactive chat or videoconference. So they trust the identity provider running locally on your devices, and no servers needed. The only question becomes how to route messages to you. Friends can leave them on various computers all over the internet, redundantly, encrypted with the public key. They just have to bootstrap the initial addressess of mailboxes somehow. This can happen when you send the public key in the side channel, but it DOES require some sort of global network like DNS or a DHT or Apple Notifications, some sort of singleton that both parties can reach. This is the ONLY need for it — for deliverability, NOT security.
  • southerntofu 7y ago
    Nice take on the issue. But why rely on the browser stack and javascript hell, though? I think the approach you describe looks a lot like the Secure Scuttlebutt (SSB) protocol : local "gossiping" with centralized hubs to relay authentication and/or encrypted information. > using DNS is straightforward to do verified claims That could be simpler in some regards, but not others. Consider most shared hosting name servers don't provide a simple API to update your zone, so you may have to do manual edits for key rolling, vcard changes, etc.. Also, not all implementations of domain names are alike. The traditional DNS is a tree-like datastore and many things (such as routing and security) are outside of its scope. But take for instance tor's onion services: they don't allow you to store/retrieve arbitrary records, but ensure the routing/authentication/encryption to the service and back. On tor, owning a name on the network is the actual mathematical proof of identity (the onion is a fingerprint of the actual encryption key) so you somehow don't need to let the DNS hold your keys for you. I think the issues you mentioned have mostly been tackled by modern P2P projects. The actual pain points are in my opinion: - the state of client applications (usually either ugly/broken or dependent on gigabytes of Electron shit that only runs fine on your dev hardware) - backup: democratizing encrypted friend-to-friend backups, but also building server-side stacks for hosting coops, individuals and companies alike to easily setup "seeding"/"backing up" of your data using standard protocols - identity recovery: people often complain loosing their data/identity on P2P networks (think Bitcoin, etc.), or regret lending it to the wrong entity (cryptoscams and hacks and whatnot). Proper identity recovery can be done either by dividing a secret among friends or with passphrase-generated private keys (or both) - key distribution: centralized key distribution is a security nightmare and web-of-trust exposes the whole social graph... i guess that's another area where we have to innovate?
• aaronpk 7y ago
  For those of you wondering how this is different from OpenID Connect: https://indieweb.org/How_is_IndieAuth_different_from_OpenID_Connect https://indieweb.org/How_is_IndieAuth_different_from_OpenID_...