Login with FedCM or IndieAuth

[erlend-sh]

https://blog.erlend.sh/indie-social-sign-in-could-go-mainstream

Domain names as handles is a flagship feature of the Bluesky network. It follows rather naturally that users ought also be able to log into the network using their own domains.

https://bsky.app/profile/erlend.sh/post/3l3itw5fqil2f

[bnewbold]

This looks intriguing! In the context of atproto handles, it seems like this could work at least two ways: folks could log in to their atproto PDS using their domain using FedCM/IndieAuth (aka, atproto PDS as the Relying Party); or they could use an atproto PDS (possibly self-hosted, possibly on their own domain) to log in to other services using FedCM/IndieAuth. Does that sound right?

We have made a big push/investment in getting out the atproto profile of OAuth (based on OAuth 2.1 and client metadata), which is related. Have you checked that out?

• Draft OAuth Spec atproto-website#326
• https://docs.bsky.app/docs/advanced-guides/oauth-client

It ends up achieving some of the same goals, and allows both authz and authn use-cases, but we didn't end up with direct OIDC compatibility.

[anderspitman]

@bnewbold sorry for the delay. I just read through https://github.com/bluesky-social/atproto-website/blob/bnewbold/spec-oauth/content/specs/auth.md. Excellent document. Honestly it's a pretty good summary of the state of OAuth2 and how to design a modern OAuth2 profile.

With FedCM, what we're really hurting for currently is RP implementations. Google's position is essentially that IdP's and users are likely to embrace FedCM, but there's not enough evidence that RPs will also do so.

So we're looking for prominent RPs to jump on board. It's a chicken/egg problem, and no guarantee the protocol gets adopted in browsers, but I personally believe it would be a big win for the open web if it did, and it's worth sacrificing to try and make it happen. So I've invested a significant amount of time in it so far.

Would be happy to talk more about the potential for atproto to get involved.

I have some additional general questions, but in the interest of keeping this focused on FedCM I posted them here: #2656 (comment)

[bnewbold]

@anderspitman we are pretty interested in FedCM generally, but still trying to clarify what would be more helpful from us: are you hoping that atproto PDS instances would be relying parties, or that folks building atproto apps would be relying parties? Or both/either?

We don't support external IdPs of any kind yet in our PDS implementation, which is both what we run for the millions of users on our servers, and most of the other instances in the atproto network. We think it is fine and great for folks to use IdPs for PDS account signup and login, but it will be a chunky piece of work for us to land and isn't on our near-term roadmap. On the other hand, having a pattern for app developers (such as https://smokesignal.events/, https://whtwnd.com/, https://frontpage.fyi/) to support FedCM as a smoother login flow would be great. And https://bsky.app might be in that category. But to clarify, all of these atproto services require a PDS account somewhere; it doesn't make sense at the protocol layer to log in to bsky.app with IndieAuth from your own domain, you need a PDS account in the mix.

[aaronpk]

@bnewbold what we're missing as far as the FedCM spec development is concerned is demonstration of interest from relying parties for this feature, so that could absolutely be atproto apps as relying parties.

[anderspitman]

I want to make sure I'm understanding correctly. When I log in to Bluesky, I see an option to select my hosting provider (which is the PDS, right?), with Bluesky Social as the default. I'm assuming if I selected my own server, I would first be redirected in some way and have to log in to it, then be redirected back and also provide my Bluesky credentials for the app? Or would the app piggyback off my PDS session and log me in automatically? Sorry, I haven't made time to dig into the ATProto architecture enough yet.

Basically I'm wondering if identity is anchored in the PDS, maybe it makes the most sense for the PDS to be a FedCM IdP, and for ATProto apps to be FedCM RPs. This feels fairly intuitive to me, where your identity is closely tied to where your data lives.

[bnewbold]

Just want to say that while I haven't had time to follow-up on this, we are very very interested in FedCM. Please do poke again or reach out to set up a meeting if there is timeline urgency.