Single Sign-On for Fediverse

I think having a single sign-on option across application could be the value-add that attracts substantial numbers of new users to the Fediverse.

It’s hard enough for users to dive into the Fediverse, when few (if any) of their friends are there yet. But if we could tell them: there are plenty of great applications, AND you don’t need to make a separate account with each one, you can use just one set of credentials to blog, share photos, microblog, social network - that would be a real compelling proposition.

I think many people would agree that SSO is convenient. The problem, as I see it, is that there are many ways that a SSO system can be implemented, and currently no consensus on the best option. My proposal would be that the group here, or perhaps in the SocialCG meeting, form a consensus on the best SSO approach(es) for the Fediverse. That way, developers can focus on implementing and developing, without needing to individually determine the pros and cons of each option.

As an example, consider that on PixelFed’s Github, there is an Issue #2089 open asking for SSO with LDAP, SAML, or Open ID Connect; Issue #935 asks for IndieAuth support; and Issue #14 asks for LDAP or other SSO support. On Friendica, Issue #1260 asks for IndieAuth support. And some Friendica instances such as Nerdica.net offer Open ID sign-on, but this seems outdated compared to Open ID Connect and other options. Giving guidance on this could allow developers to focus on developing.

Here are the options that I have seen discussed:
Open ID Connect
IndieAuth: https://indieauth.com/
KeyCloak: https://www.keycloak.org/
Gluu: https://gluu.org/docs/gluu-server/
SQRL: https://en.m.wikipedia.org/wiki/SQRL
Zot protocol: Nomadic identity and Remote Authentication Zotlabs

Or perhaps address this through ActivityPub’s Client to Server Interactions.

What do people think? Is there guidance that can be developed? Are any of these approaches better than others, or additional options that should be on the table?

4 Likes

Zot’s magic-auth is now called OpenWebAuth and is implemented on Hubzilla, Friendica, and Zap.

It’s a way to “link” a browser cookie from one domain to a browser cookie in another domain using HTTP signatures and webfinger. It is described here:

The original goal was to provide access control across domains but now has a much wider scope. It was used to provide private photos and videos (ACL) but this technology has been shunned by this community in favour of OCAP. I’m mentioning the original purpose not to start another shitfight but so that folks will understand the original intention of a cross-domain authentication and SSO mechanism that involves zero user interaction. This is important if you have a hundred access controlled photos in your morning stream and the reason this wasn’t based on OAuth/OIDC/SAML/whatever. It was originally based on the design of “password-less ssh” but is now easier and involves less overhead since it was re-written to use HTTP signatures. IndieAuth is a much simpler mechanism overall, but requires you to have write access on each linked server which sort of implies you need to already have an account there in order to create the link. OpenWebAuth does not require an account or any pre-existing knowledge at the destination endpoint. LDAP is fine for linking services across an organisation but is centralised and probably wouldn’t be a good fit for this purpose. You can also just use OCAP to do most of this (including SSO) - but I’ll let others decide if that is the right tool for their needs. It wasn’t for my work.

I am not promoting any technology, but merely discussing the reasoning behind engineering decisions that I made a decade ago when I looked into how to bind smaller fediverse sites into a larger whole where people could flow between diverse sites and use services and access restricted content without encountering login prompts, boundaries, or other hurdles.

5 Likes

Thank you @mattyp for starting this up!

I would like to see some comparison or research in SSO, and I would suggest this can be funded, either by NGI0 PET[1], or NGI-POINTER, as an inter-disciplinary group bringing together various approaches. If you’re interested in tackling this issue, I’d be happy to help within the +community:public.cat scope.

I’m currently using Keycloak mostly with SAML for PUBLIC SSO and would be delighted to expand this service to a larger portion of the Fediverse. Besides, I really like the self-sovereign identity (SSI) approach taken by the GNU Name System called Re:claim ID – what do you think?


  1. there are a number of related projects already funded in this direction:

    ↩︎
3 Likes

Do you have pointers to the discussion? I am interested to know the considerations, and the resolution / compromise (or not) they had.

1 Like

There was a long discussion about OCap during APconf 2019 and the special guest and keynote speaker was Mark S. Miller whose thesis was on object capabilities. Of course there’s the OcapPub topic here that links to Chris’ paper and Sebastian’s notes of the live session.

As you can see in this picture from @maloki’s blog of the sticky board, the OcapPub session was pretty much something everybody wanted to attend :slight_smile:

2 Likes

Thank you!

PS. I recently asked @cwebber on the fediverse about zcap-ld and its relation to the the fediverse, and here is his answer:

zcap-ld is one way to implement ocaps. Is it the right one for the fediverse?

There are really three viable paths for a fully rich federated social network:

  1. “sufficiently unguessable” ocap URIs (ocap literature: “sturdyRefs”)
  2. ocap certificates (eg zcap-ld)
  3. live references (requires CapTP, which I am working on)
  4. and ok also technically ocap powered storage (datashards)
  1. and 4) are the easiest tie-ins to present infrastructure, but…

  2. is going to be desirable if you have a lot of, er, “fast and furious short lived ocaps”, as a virtual world would need. That’s probably not necessary or within the scopes of most others right now.

  3. is nice, and I’m a big enthusiast of zcap-ld, but it’s kind of a jump in tooling vs the amount of payoff available for most implementors right now (whereas 3 is a big jump in payof while also being an increase in tooling)

I’m not really answering your question clearly, so basically: I think bearcaps + datashards (or something like either) for networked ocaps and storage are the fastest path to global fediverse adoption of ocaps.

(But for the virtual world stuff I’m working on, we’ll need CapTP too… but I’m not expecting most fediverse developers to take interest in that yet.)

3 Likes