Rauthy for fediverse logins

[erlend-sh]

Quick primer on the fediverse and its importance:

• https://www.theverge.com/2023/4/20/23689570/activitypub-protocol-standard-social-network
• https://knightcolumbia.org/content/protocols-not-platforms-a-technological-approach-to-free-speech

Both the primordial fediverse of ActivityPub (Mastodon & friends) as well as the federated Matrix have been mulling over various private-key approaches to the ideal of "nomadic" or "decentralized identity", but I think they’re trying to solve too many deep-rooted problems in one go, keeping them in a holding pattern for many years:

• https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101
• Decentralised user accounts matrix-org/matrix-spec#246

With the convergence of OAuth/OIDC in both protocols there's potential for OAuth self-hosting to serve the function of a minimum-viable ‘nomadic identity’.

• https://docs.joinmastodon.org/spec/oauth/
• https://matrix.org/blog/2023/09/better-auth/
  • https://areweoidcyet.com/

This Kitsune issue is an exploration into OAuth as a stepping stone towards what could later grow into a full-fledged Nomadic Identity, but starts off as just a personalized OAuth server.

minimal definition of user agency:

• Own your ID
• Own your content
• Own your contacts

---

Rauthy has a clear path into the fediverse ecosystem by providing the OAuth backend for Lemmy, which is already running in production on some thousand instances.

• OIDC single sign on LemmyNet/lemmy#2930
• OAuth (2.0) LemmyNet/lemmy#1368

Note that there's a lot of fluctuation and mixups in these spec discussions, but there's now consensus among the core devs that OAuth is a desired feature, first and foremost for SSO, but tentatively also as a provider. For a while a custom implementation was being considered, but it was eventually abandoned in favor of standardizing around OAuth.

[sebadob]

SSO is basically the opposite of decentralized of course, but yes with Rauthy you do own your data, you have control over it, and so on. When you have a setup that can dynamically resolve to different SSO providers just for ease of use, fault-tolerance or just for the reason of having different servers like matrix does, then this could make sense again.

In the early days, I did all my authn/authz custom as well. The problem is, that it only works with your own apps and everything else just becomes a mess, where you need proxies, adapters, or something like that. I liked Keycloak and what it could do, but I hated that updates often broke stuff for me and that it just consumed too much resources for my liking.

Rauthy is not an OAuth provider, but OIDC, which is actually a superset of OAuth.
When you are speaking about identities, you usually want OIDC instead of OAuth, since OIDC actually provides information about the user, which OAuth does not really. Rauthy will get more (optional) possibilities to save information about the users identity.

[erlend-sh]

I've written up an extended formulation here: https://socialhub.activitypub.rocks/t/autonomous-identity-for-the-pluriverse-based-on-oauth-oidc/3675

[erlend-sh]

https://github.com/bluesky-social/proposals/blob/main/0004-oauth/README.md

[sebadob]

I did not have time to read the full draft yet. A few of these points are already supported by Rauthy, but they require a lot of stuff which will create problems with others.

The (very annoying) thing is, that there are so many drafts, proposals, and so on out there that try to solve the same issue - dynamic SSO logins. Solid OIDC does a nice job imho. I really don't get it why people cannot get together and the whole community will simply have one thing, that just works. But instead everyone is doing his own thing, while none of them is "official", stable or something like that.
That makes it insanely hard to keep track of everything. And, if for instance Rauthy would implement all of these, it would simply make each login flow so much more inefficient because of all these additional checks to find out, which of these mechanisms and flows is being used each time.

These are the points they don't like about the (official) OIDC dynamic client registration, why they decided to create this big whole new non-standard thing:

• Clients need to keep a state for all the AS they registered to, making them harder to implement and maintain.
• The client credentials obtained from the AS during the registration can get lost, without any way for the clients recover them autonomously.
• The protocol does not provide a good protection against "theft of identity" (a non-legitimate client registering with the same name, logo, etc. as another, legitimate, client).

So the reason to have their own thing is because apps would need to keep track of their client data (which is a tiny dataset). Instead, each SSO provider would need to implement a lot of non-custom stuff that will just interfere with all other mechanisms and properly working clients.
Then, client credentials can get lost? Then they would have huge security issues and it would actually be a good thing, that you cannot automatically recover them.
The last point is true in any "dynamic" situation, which is why I exclusively use static clients in all my apps and deployments. Apart from being much faster and more efficient, it is really not such a big deal to register a client you will need with an application.

[erlend-sh]

Bring your own IDP:

https://wrily.foad.me.uk/sign-in-with-big-tech-only-or-sign-in-with-whom-i-prefer
https://www.liquid.surf/2024/2/7/Can-FedCM-improve-Solid-login-flow

Working prototype in chrome canaries: https://github.com/fedidcg/FedCM/issues/240#issuecomment-2004650817

[sebadob]

This is a bit off-topic, but when then Firefox and others support the largeblob extension as well, I will be very happy. :D

[samuelgoto]

Probably behind a feature flag for the beginning, but it could be used for more in depth testing then.

Behind a flag sounds perfectly reasonable to me. Thanks!

This is a bit off-topic, but when then Firefox and others support the largeblob extension as well, I will be very happy. :D

https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/WebAuthn_extensions#largeblob

Is this what you mean?

[sebadob]

Is this what you mean?

Yes! This will make it possible to store stuff like encryption keys fully on the client side inside the passkey.

[samuelgoto]

K, I can bug them and see where that takes us.

[sebadob]

https://caniuse.com/?search=largeblob
Safari and Firefox on the Desktop are missing and Android in general, but when this lands everywhere, we can have portable and secure e2e encryption everywhere. I am working on something regarding this in another project.

[erlend-sh]

Useful references:

• https://indieweb.org/FedCM_for_IndieAuth
  (relevant to IndieAuth and RelMeAuth #146 )
• https://github.com/Liquid-Surf/fedcm-test-suite & https://github.com/Liquid-Surf/fedcm-demo
  (relevant to Extending with custom client resolution #133 )