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


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.


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


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:


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


Would this work if the services are on different hosts / servers. I know that it works with debian as I can use salsa to sign in to the gitlab (salsa) moodle, peertube but I think they are all hosted in the same place.

But yes a single sign on would make it a lot easier for people. But many may also expect that to be backed up with 2 factor authentication.

1 Like

For 2 factor will make things easier I guess.
and @macgirvin
Would prefer if we can speak about it.
Can you attend the Social CG next week, SAT?

See “Generic Servers” - if more people would use the Client2Server portion, it would be a good start …
We could schedule a meeting for a group who want to work on that …
For slow-me 1 day talking is like 1 week writing :wink:

Apologies for bumping this topic, not sure the correct etiquette here

But I was just wondering if we got any further with Single Sign On

I’ve been using SSO via my home page in a federated way since about 2007, and I absolutely love it. We used the WebID-TLS system for many years, but that seems no longer to be actively maintained

One aspect I really love is that you can build apps without worrying about user management, that can be outsourced to another piece of software, or your home page

It seems to me that it could be done quite simply, and then improved upon, iteratively


  1. Send a Login activity to your outbox, stating which app/site you wish to log into

  2. Your outbox provider signs it and forwards it to the inbox of your target

  3. You are returned an unguessable string which enables you to log in, on a one time bases, say for 15 minutes

Could it work? Or is something better in use?

1 Like

Sounds like a good idea, however using multiple servers may cause problems with data protection.

Qoto has mastodon, peertube on a single server or place, so SSO would probably work there fine.

Not sure if it would work as well if data has to be shared between instances and instance owners


1 Like