IndieAuth
Nearing a decade ago, made a compelling case for IndieAuth, a "decentralized identity protocol built on top of OAuth".
OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.
While OAuth is a great framework for this, the way it has ended up being used is much more centralized and closed than prior efforts
Instead of social-web platforms defaulting to the single sign-on hegemony of Google/Facebook/Microsoft(GitHub) as the only options for quick sign-in, what if there was one universal field where all auth providers were equals?
IndieAuth, built as an extension of the ubiquitous OAuth standard, lets you login with your website.
This evens the playing field, genuniely democratizing OAuth as the universal method of internet login.
Unfortunately it never made it to mainstream adoption. No matter how universal, single-field-of-text just can't compete with single-button-click.
The only way to solve for that is in the browser.
FedCM
A lot can be said about the maligned incentives of Big Browser incumbents to maintain their comfortable status quo and why it's taken a decade for tangible progress to be made on this end, but instead of dwelling on the past we can look to the future that is the FedCM standard:
FedCM, developed by & co., turns the finicky text-entry into a streamlined button-click (auto-click even) by keeping your default website-logins stored for you.
Presently this only works in Chrome browsers (then again that's like 65%-75% of all netizens already), but the rest are coming along. This will be further helped on by the Bluesky-funded work on FedCM being done by to align it with the open-social web.
Atmospheric OAuth
The AT protocol had to develop a more decentralized alternative to OIDC in order to fit atproto's open-social identity system onto OAuth.
The result was the atproto-oauth spec.
CIMD
@atproto/oauth-provider diverges from OIDC by supporting CIMD, which is essential to auth flows like that of IndieAuth.
Client ID Metadata Documents (CIMD) let OAuth clients identify themselves using a URL. No preregistration necessary.
DID:PLC
It's also compatible with atproto-identities, which grants users of atmospheric apps the critical affordance of credible-exit. The did:plc method is what makes this possible.
It's a centralized registry, but it's easily replicable and held in a non-profit foundation1. There's even a clear path towards greater decentralization in the future, it's just not an urgent need given how reasonably anti-fragile the system already is.
With all of the above combined with FedCM we get a web-wide login experience that rivals the hegemons.
Atmospheric Login Diary 1: On the Button
Atmospheric login is one of those topics that maintains a constant hum of discussion in our ecosystem, and for good reason: it's how everyday folks make their way into our burgeoning, internected web of apps. I'd like to explore this in some depth, so consider this the first of several diaries. As someone whose job description says, verbatim, “grow the Atmosphere”, open questions about login have become something of a fixture in my mind. Because there are some real stakes here for the network. A...
We have users knocking on our doors: let’s give them a best in class first impression of the Atmosphere and set them up for their next run-ins with us.
I believe there are really just two key components to set us on our way to Web future.
A recognizable login button. When users see it they know they can login with their Atmosphere account. And they will come to expect an Atmospheric experience once they’re in.
An account picker that feels like it comes with you across the Atmosphere. If a user already has an Atmosphere account, they should be no more than three clicks away from using your app once they discover it.
IndieAuth v2 is already here
As a participant in the atmospheric web I am already enjoying the "IndieAuth v2" experience, made up of atproto-oauth, FedCM and did:plc.
What's been achieved with AT protocol identities is arguably not very far off from the essence of WebID2 either. For the end-user it's functionally doing the same sort of thing:
WebID-based protocols offer a new way to log into internet services. Instead of using a password, the member refers to another web address which can vouch for it.
I'm just throwing that out there because in my humble opinion the general (O)Auth & (D)ID pattern outlined by the AT protocol is what I've always wanted as my personal WebID, and I think most internet users would agree if they could share in my experience.
This doesn't need to be an atproto thing. It's an OAuth and DIDs thing. Other protocols can introduce alternative, even cooler DID methods than the Atmosphere's PLC.
The easiest way to supersede the did:plc whilst benefiting from its ecosystem is to follow the pattern of did:plc:bft which simultaneously acts as a mirror and an alt-method with additional, even more decentralized capabilities.
From a foundational point of view, didplcbft is designed to operate independently from plc.directory, such that it could eventually replace it, becoming the de facto PLC service. However, as a transitional approach, didplcbft can act as more of a mirror of an authoritative PLC implementation, namely, plc.directory.
This is how other networks like ActivityPub and Matrix could hop on the DIDs bandwagon.
Distributed identity across the social web
There was recently a great convening of social-web stewards from across nations and protocols.
One section commits the signatories to a common identity stack.
What the signatories intend to build together.
(...)
The development of a system for a distributed identity that can be used across networks and beyond (e.g. the European Digital ID Wallet) and protects personal data.
The IndieAuth/WebID-like pattern is another such distributed identity system that can be used across networks, and in a much more global and neutral way than EUID.
For ActivityPub this pattern has largely been proven out already in NomadPub.
Matrix implements OIDC, it just needs to adopt the DID pattern instead of the myriad other paths it has deliberated over for the past decade.
With FedCM, OAuth and DIDs as the unifiers, we wouldn't have to talk about logging in with "atmosphere/bluesky/mastodon/fediverse/web3"; just log in with your Open Social Web ID.
more about the Atmosphere:
What is the Atmosphere?
An explainer for everyone in 4 minutes or less.