
IndieAuth – A federated login protocol using one's own domain name - pmlnr
https://indieweb.org/IndieAuth
======
djsumdog
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/)

------
splitbrain
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.

~~~
libeclipse
How about... asking them for it?

~~~
wukerplank
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
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
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
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/)).

------
sirius87
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
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.

~~~
pvorb
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
OIDC is wonderfull and I have no idea why OpenID put their name on it. "OAuth2
Auto-Configuration" would have done it.

~~~
pvorb
Yes, absolutely. If it was called something like "OAuth 2 Auto-Configuration
and Identity", it would have caused less confusion.

------
robtherobber
Silly question: what's the difference between IndieAuth, Auth0, 10Duke, Citrix
and others when it comes to security, please?

~~~
aquabeagle
IndieAuth is an open protocol, the others are companies with proprietary
products.

~~~
robtherobber
Thanks!

------
raxxorrax
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
Out of interest, why would you prefer not to use your domain? Privacy
concerns?

~~~
raxxorrax
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.

~~~
southerntofu
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.

------
aaronpk
For those of you wondering how this is different from OpenID Connect:

[https://indieweb.org/How_is_IndieAuth_different_from_OpenID_...](https://indieweb.org/How_is_IndieAuth_different_from_OpenID_Connect)

------
EGreg
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
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?

------
bullen
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

~~~
buildzr
Congratulations, if I'm not mistaken you just defeated the entire purpose of
hashing passwords.

The point is that the server doesn't store what's used to verify directly, it
needs to provide something that can generate it. The way you're doing it,
someone can dump your DB and login as anyone. If you want a secure way to do
this maybe look into SRP or similar PAKE protocols.

~~~
tragicpapercut
This is why you shouldn't "innovate" with encryption unless you are a trained
cryptographer (or equivalent). Cryptographers may be programmers, but
programmers are not cryptographers.

~~~
zaarn
You don't need to be a cryptographer to know that you don't do plaintext
passwords.

~~~
pvorb
But it seems it wasn't obvious to bullen that this way the password is
essentially sent in plain text. So yes, let your authentication be analyzed by
an expert or use standard software.

