Post AkusYcnRXfuLIYjmts by fentiger@zotum.net
(DIR) More posts by fentiger@zotum.net
(DIR) Post #AkSaAKnVZVHuvO9qVM by fentiger@zotum.net
2024-07-30T15:12:15Z
2 likes, 0 repeats
Anyone interested in single sign-on / #SSO? Want a new toy to play with? I've been experimenting with it recently, and now I've got something to share: an experimental demo of how a "Sign in with the Fediverse" mechanism might work.If you have a Mastodon or Hubzilla account, or an IndieAuth-style self-hosted identity, I'd like to invite you to try and sign in to my test site at login.mythik.co.uk.Headline features: User authentication/authorization based on the Ory tools. Supports signing in using an existing Fediverse (or other) account - or one you host yourself Open source - well, not yet, but it could be, if people are interested in it Written by a non-expert! Woefully insecure! All manner of attacks, just waiting to be found! Invite your security expert friends to the party, and laugh together at the n00b! Fun for all the family!Supported identity providers include: Mastodon (must be a recent version that includes this pull request). mastodon.social is known to work. Hubzilla (any version). zotum.net is known to work. #IndieAuth / #FedCM Another instance of itself, using OpenID Connect(There's a chance Streams might work, too.)Protocols supported: #OIDC Discovery Client ID Metadata Document FedCM for IndieAuth #OpenWebAuth A method using the Mastodon API Classic (non-FedCM) IndieAuth (if you're lucky; I found this very hard to test, and had various problems with it) My original experiments used Dynamic Client Registration but I've moved away from this.If you can get it to work - share a screenshot and let me know what you think!(I'll try to keep this running for a while, but I can't guarantee it - partly because I haven't finished trying to attack it yet. If I have to take it down for some reason, I'll edit this post to say so.)
(DIR) Post #Akr0P6Kmt9PV0tSptI by silverpill@mitra.social
2024-08-11T10:02:35.922144Z
0 likes, 0 repeats
@fentiger What it is supposed to be used for? Sharing login credentials?
(DIR) Post #AkrctSNHIx52JcWxw8 by fentiger@zotum.net
2024-08-11T16:09:33Z
0 likes, 0 repeats
@silverpill Yes. It lets you log in using an existing account rather than having to register a new one - but in a "Fediverse compatible" way, without any of the technical and social problems which come with using a Big Tech provider. It can also (in some, admittedly limited, circumstances) recognise your login session automatically, without having to actually enter your ID every time you click from one site to another.
(DIR) Post #AkrctT1Ku17gJrGxNI by silverpill@mitra.social
2024-08-11T17:13:46.946468Z
0 likes, 0 repeats
@fentiger If you log in using an existing account and create some ActivityPub object, what actor will be used? A new local actor, or an existing one?
(DIR) Post #AkusYcnRXfuLIYjmts by fentiger@zotum.net
2024-08-12T12:49:17Z
0 likes, 0 repeats
@silverpill Good question. Quick, shallow answer: this is just a login system, not an #ActivityPub instance. It could certainly be used in front of an ActivityPub instance, though, and in that context, it's definitely worth thinking about. I don't have any concrete answers, but off the top of my head:The simplest option would be to create a new local actor, and use this purely for login. Sometimes this is the only option - IndieAuth and the native OIDC mode can both work without the existence of an AP actor at the IdP end.Another option would be to pair it with AP C2S. The OAuth2/OIDC based modes can provide an access token as well as an identity; this could be used to authorise the RP to connect back to the IdP and post using C2S. This would take a bit of standardisation work, but not a lot; my impression is this would be fairly easy to build.What if the user has a FEP-ef61 nomadic actor? Sending the private key from the IdP to the RP is probably not a very good idea, but perhaps the IdP could expose an access-controlled endpoint to generate a signature on the user's behalf. With this method the RP would construct an object with attributedTo set to the user's nomadic actor ID, request a signature from the IdP, and then distribute the object however it chooses. (In this case, perhaps the IdP should get to choose the new object's ID too, at which point this starts to look a lot like a variant of C2S.)
(DIR) Post #AkusYdg2GhZo1sHNzc by silverpill@mitra.social
2024-08-13T06:53:33.741395Z
0 likes, 0 repeats
@fentiger>What if the user has a FEP-ef61 nomadic actor?>perhaps the IdP could expose an access-controlled endpoint to generate a signature on the user's behalfThis should be possible with did:web authority (existing implementations use did:key). I haven't yet researched what our options are, but here are my bookmarks related to this problem:- https://openid.net/specs/openid-connect-self-issued-v2-1_0.html- https://w3c-ccg.github.io/vp-request-spec/#did-authentication- https://git.juici.ly/consensual/federated-auth-network/src/branch/master/SPEC.mdAlternatively, FEP-ae97 provides a different path to nomadic SSO where identity key is stored on a client side, so users can simply copy their key when switching clients. As long as activity integrity proof is valid, it would be accepted by servers.