Authentication Servers

[1WHISKY]

Issue

If you join five different Revolt (self hosted) instances you have to create five different accounts for each instance.
This can get annoying because you have to create a account even if you are planning to join that instance temporarily.

Also you have to trust the hoster that he did not tamper with the service in order to sniff your entered credentials.

Possible Solution

Create a publicly hosted authentication server where people can register.
Additionally you can host your own authentication server.

Once you join a self hosted instace you can choose a authentication server using a drop-down menu.
If you choose to log in using the public authentication server you will be redirected to something like auth.revolt.chat and once you logged in you will be returned to the self hosted instance.

The available/allowed authentication servers should be configurable (e.g. .env).
Maybe other login providers (oauth2) could be included so you can log in with steam, google etc..

Problems

There are probably many issues with this suggestion and my suggested solution is probably not the best.
What happens if two people join a self hosted instace with the same name from two different authentication servers?

Feel free to comment how you would implement such an authentication system

[insertish]

What happens if two people join a self hosted instace with the same name from two different authentication servers?

Ideally I would do it so that each instance can only connect to one other authentication server.

[Eragonfr]

An other method is to federate the autentication servers. So only one person can claim a username

[surfaceflinger]

So only one person can claim a username

IMO it would be better if user had some kind of immutable "friend code" derived from private key stored on an authentication server, and they could set any display name they want. This would also prevent the "OG" cancer.

[mkg20001]

Another thing to consider is OAuth2 (Sign-In via Google, etc)

Self-hosted servers could, maybe even by default, offer "Sign-In with revolt.chat Account"

[oleggtro]

Just use a password manager lmao

[mkg20001]

Ey get your ego somewhere else. It's a useful feature for some people.

[oleggtro]

ok, but we're really off topic now

[tallship]

OpenID/OAuth2 Plugin capability

Service can be easily enabled based on administrator preferences to support other AUTH/SSO methods

Another thing to consider is OAuth2 (Sign-In via Google, etc)

Self-hosted servers could, maybe even by default, offer "Sign-In with revolt.chat Account"

Basics of enabling the capabilities like many other platforms services do:

This is a good idea. I don't think it is necessarily a good idea to be worrying about it at this particular time however, but many sites afford the userbase the opportunity to either create a new account or connect their account to a third party authenticator service. platforms like Discourse, Dev.to, NextCloud, and others enable this (in addition to many that also offer Google, Faceplant, GitHub, etc.).

This is typically enabled by installing the capability via the native plugin architecture of platform, so that it would be a decision on the part of each Revolt instances administrators.

Many of us already offer these capabilities for our communities, especially those of us who operate many different types of platforms, providing an SSO solution for those users who choose to enable it for themselves on their respective accounts; and many of us also operate the OpenID/OAuth2 provider services to facilitate this. One free solution that I personally like is:

https://github.com/DuendeSoftware/IdentityServer (Easy Peasy to deploy)

Again, this wouldn't be built into the core of Revolt, but rather, as an optional service/plugin to enable depending on the needs/preferences of the administrators of other self-hosted Revolt instances. The Revolt server admins could also choose from amongst other various providers (besides their own OpenID/OAuth2 provider service) like GitHub, and the evil monolithic silos like Google, Twitch, and Faceplant.

The flow would work this way:

• User signs up by creating a new email based account on the Revolt server, then later, choses to connect the SSO Auth service to their account - thereafter, they can login using either method (i.e., using OpenID/OAUTH2 or via email/username).
• User signs up with the external auth provider where they already have an identity (i.e, using their OpenID/OAUTH2 provider account).

Other Revolt and different kinds of platform instances independently decide whether they want to offer these additional types of authentication methods at their own prerogative.

I'm interested in hearing other's thoughts on the matter, and will eventually probably open an issue directly related once Revolt matures a bit - in the meantime, the development cycle of the project is seemingly too aggressive and tending to more immediate matters/issues on the projects roadmap to detract from such a tertiary plugin integration.

⛵

.

[erlend-sh]

Self-hosted servers could, maybe even by default, offer "Sign-In with revolt.chat Account"

For this I highly recommend https://github.com/sebadob/rauthy

[oleggtro]

maybe rename this to Server Federation ? @1WHISKY

[walmir]

Hello,
Is there an update on this?
I need this on a self-hosted instance. The goal is to create a single account on an auth-server for multiple apps including revolt.chat.
If this hasn't been done, or planned yet, I'm considering implementing it myself.
I'm happy to discuss other requirements and sharing results :)

[Fifthdread]

I also need Authentication Server support for my self-hosted instance. Specifically I want to use Authentik. I hope it gets implemented at some point.

[Zipdox2]

I second using the official Revolt server as an Oauth provider for self-hosted instances.

[secondtruth]

That is a good idea for now, but in the long term, I think Federation would be the best solution to keep centralization low. There's also the emerging Polyproto protocol, which is modeled after Discord and could be implemented instead of ActivityPub or Matrix.

See @erlend-sh's reply to another post for more details about this and federation in general.

[Zipdox2]

hmm

I decided that for a federated chat app to succeed it needs to be purpose-built application and not some generic federation protocol detached from any specific implementation. I have been brainstorming an architecture that I may turn into an actual project. If you are interested in contributing let me know.

[tallship]

Perhaps as a plugin, which 3rd party providers could leverage for other, additional networks? Something that implements this methodology for example, is Hubzilla - even for ActivityPub, the individual user must activate the plugin to enable their own account to engage with that network.

[bitfl0wer]

hmm

I decided that for a federated chat app to succeed it needs to be purpose-built application and not some generic federation protocol detached from any specific implementation. I have been brainstorming an architecture that I may turn into an actual project. If you are interested in contributing let me know.

I am just interested in why you think this way about p2, and I'd like to hear your reasoning behind it, is all. polyproto is purpose-built to make an app which does not need to do much explaining at all to people unfamiliar with the concept of federation, so this feedback makes me curious. Since this is a thread about Stoat, do feel free to write an email about it to flori@polyphony.chat, or a message to our forum at https://polyphony.zulipchat.com/

[Zipdox2]

I am just interested in why you think this way about p2, and I'd like to hear your reasoning behind it, is all.

What is p2 in this case?

[anotherdoesnm]

I am just interested in why you think this way about p2, and I'd like to hear your reasoning behind it, is all.

What is p2 in this case?

PolyProto (repeated P are changed with 2)
like I2P - Invisible Internet Project

[terion-name]

SSO is a must for such product

[Obnyr]

I disagree. Let's say one day the authentification server closes. What do you do ? How do you get your things back ? Having multiple accounts is the right way to go, so even if one host fails, or if hosts can't communicate between them anymore, you can still access your data everywhere. Centralisation should be avoided.

However, it is true that creating an account for every host is exhausting. A tool to automate account generation on a new host is not a bad idea. Like you could link a vault to your session, and the newly automatedly created account would then be added to the vault like KeePassXC or Bitwarden. That way, you don't have any hassle creating a new account, a new password etc, but you keep access to them.