What auth platform should we implement on an #activitypub app? I see most places are using email sign up, but that means the user has to maintain a separate password and account per site.

Is there an OpenID implementation or other federated solution we should use for this? If not, can we agree on a standard one that most fediverse apps support to make onboarding users easier? We probably have enough scale with the fediverse to get traction.

@iamduck There's Portier, which (disclaimer) I'm involved in: https://portier.github.io/

But progress is slow, and it's still rather much beta.

Basic premise is a simple email loop (like https://passwordless.net/), but 'upgrade' to a provider-specific mechanism if possible. (e.g., google login for gmail, may reuse existing browser session, etc.)

Portier - An email-based, passwordless authentication service

@kosinus Thanks! I came across this one already, it does look good but looks like WIP still as you mention.
@kosinus So far I'm leaning towards https://gluu.org/ They seem to be not too coporate / trying to upsell services, but also quite full featured with minimal work to get up and running
Digital Identity for Workforce and Consumer

Provide seamless and secure digital experiences with the level of customization and control your business requires.

Gluu Identity and Access Management

@iamduck Looks decent! They do a bit more, looks like, including account mgmt.

Portier (and passwordless) do just auth. Before Portier, there was Mozilla Persona, and one of the issues with it /was/ the account mgmt. Users weren't aware they had an account/session on Persona, because all they were interested in was using <app>.

And Persona was centralised. Doing federation on top means an account at each instance?

Sorry if I'm pushing ideology too hard. 😉

@kosinus I think we should build a Mozilla Persona for the #Fediverse, and integrate it into as many #activitypub apps as possible.

Users should still be able to use a different provider. In this screenshot there is a centralized provider "apAuth", but the user can provide a URI to another provider.

The UX for logging in with "apAuth" is SO much better than a username/password or BYO provider, I think we need it even if it brings a small amount of centralization around Identity.

@iamduck In that example, apAuth is username/password but with a shared session at the (centralised) SSO provider?

I think SSO in general is a step up! Certainly better than everyone rolling their own auth.

(I don't think the OAuth / IndieAuth thing that way will work, though. IMHO, OpenID has shown that endpoints and URLs as a login are a bad experience for users.)

@kosinus yes, exactly! apAuth would be like "login with Facebook" except you're trusting an identity provider that's fully FOSS and built around identity for the fediverse rather than for data harvesting.

Kind of agree about the URI point, I include it so there's an option for users running their own instance or coming from an unknown instance to authenticate themselves. I can't see another UX-friendly way to do it though...