Can somebody please tell me how lemmy implements auth? If I sign-up to an instance, who manages the login credentials for my account to validate login attempts? If it’s with the instance manager, am I at the mercy of the instance to keep my login credentials safe? What about when logging in with 3rd party apps like voyager or alexandrite, are my login credentials passed to those 3rd party apps in clear text to validate with the instance that hosts my account.

Ideally, I would want the auth to be handled by one centralized authority that I can trust to keep my credentials safe, instead of trusting instance managers or 3rd party apps not only to store my credentials but to validate auth as well. Is that something that can be implemented for each ActivityPub software? As in auth for all instances of lemmy is handled by lemmy, mastodon by mastodon, misskey by misskey, etc.

E: I’m talking about user authentication, in case that wasn’t clear.

E2: This discussion would be more suited on each software’s development platform. But I will leave it here to get other people’s perspectives.

    • zedage@lemm.eeOPEnglish
      2·
      2 days ago

      There’s a whole multitude of resons that could be argued for both approaches. I prefer this option because:

      • Most people don’t follow cyber security best practices and reuse the same password on multiple platforms. Currently, you have to trust the instance managers are competent enough to secure their databases properly from unauthorized access.
      • Again, your average netizen does not have relay addresses for every service they sign up to. If my instance manager does not like what I say, they can publish my sign up information and dox me. I don’t want instance managers to have this power.
      • If I want to use somebody else’s front end to browse on a browser, I have to pass my credentials to them to validate authentication details. Again a huge security risk if the hosting service for the front end is malicious. Why leave this vulnerability when there is a better alternative.
      • Your average netizen does not want to familiarize themselves with the nuances of the implementation of each fedi software. They want a seamless experience with the same trust framework of legacy social networks, where they trust their data is safe. Not everybody is going to know that their sign-up information and login credentials are managed by each instance, with anybody having the ability to spin up an instance.

      Why would you not want to trust the developers of each fedi software to hold this information, instead of trusting every instance manager to hold this instead? IMO that is a more vulnerable design choice instead of having a central authority managing user authentication, unless I am missing something?

      I suppose this discussion is more suited on each software’s github instead of a place to discuss this instance in particular, I didn’t know how each software implements user authentication so I posted here.

      E: I can now see why you are alarmed by my question. That is actually a good point. I am not sure if user authentication being handled by a central authority would violate principles of decentralization, which emphasize on interoperability and freedom of movement between different software and instances, instead of implementation of one component. I’m not sure if the management of authentication needs to be decentralized in the fediverse, as decentralization of freedom of movement itself is sufficient to prevent undesirable software implementations. I’d argue that managing authentication by instance managers is still a concentration of authority, albeit it is less centralized than a single source of truth. But I would love to hear arguments for why managing authentication by a single source is dangerous.