Single Sign-On for Fediverse

Fediversity
1

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?

6 Likes
2

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.

8 Likes
3

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:

    ↩︎
2 Likes
4

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

5

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:

1920×1080 380 KB

2 Likes
6

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
7

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
8

For 2 factor https://webauthn.io will make things easier I guess.
Also
@mattyp
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:

9

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

Design

  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?

3 Likes
10

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

Paul

1 Like
11

has there been any more work done on this topic?

12

I’m planning to implement SSO with DIDs, but the current work is mostly focused on introducing DIDs to Fediverse without breaking federation (e.g. FEP-c390). The work on identity providers hasn’t even been started yet.

2 Likes
13

SSO is so obviously core to the growth of the #Fediverse and the #openweb reboot that It’s hard to see why we don’t have a good enough #KISS solution in place and in use.

There are a number of “good enough” implementations, can we maybe take the time to revisit and outline the pros and cons of each one, so we could maybe try and build a “social consensus” on a path on this core issue.

As far as I can see, I think the purely technical path is HARD blocked, so the only path we have forward is social.

1 Like
14

There are multiple technical paths, and some of them remain unexplored.
I think it is a bit too early for trying to reach consensus about the best solution.

15

FWIW I wrote the first SSO implementation for Solid back in 2007 and have been using it ever since. It’s very useful and the thing that got me into the social web. Nostr has it as a work in progress with NIP-98 and it’s a feature I personally use more than nostr itself. A simple SSO system for fediverse would be great.

I am NOT a fan of the current DID system, because it’s not just one spec, its more like 170 different specs, many of which are primarily aimed at selling very dodgy tokens, that have been deemed fraudulent and illegal in the US and other places. I have tried to ask them to clean this up, but currently they have yet to do that.

I favour a PKI approach, or delegated PKI approach which can be done in the HTTP handshake, then put your key in your profile. This also works well with browser extensions.

16

Hi everyone,

I’m really interested in SSO for the Fediverse, as it might actually help bridge user base throughout the network.

The issues we have right now :

  • Many users struggle to find the right instance/service to use and where to create their account
  • Users have to create new accounts on several instances/services
  • Instances and services can’t reliably authenticate users without going through tool specific API
  • User data is scattered and not normalized, making it harder for user to use other services, as they need to recreate that information in those services (of course sometimes they want to keep it private/different, but other times they just want to have them available through the newly used instance).

Existing use cases :
We can see that lately, some services have been implementing sign-in through another service, like Pixelfed who implemented Mastodon sign-on.
We can also see that some services are being created inside other services, like Peertube and its Livechat plugin, where the user might need to be authenticated with Peertube or inside the Livechat service (or through Prosody/XMPP).

Other things that might be interesting to connect to that :

  • Data standardisation, to give the possibility for different services to share and edit common data without breaking usage or user’s profile
  • Supplementary account access permission to handle data sharing in an ethical way for users