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

[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]

I don't think Polyproto passes the grandma test. I've been brainstorming an alternative system.

[terion-name]

SSO is a must for such product