A comparison of eleven open-source SSO solutions

In this second article, dedicated to the management of our technical infrastructure, we present our research work on unified authentication solutions for the sake of transparency and spreading knowledge.

As you can imagine, these articles are exceptionally aimed at an expert audience, but you can also find our article on our digital support program or our new service offering if you prefer to read more accessible content.

This article follows the presentation of our hardware in which we showed the servers we self-host, and will be completed by an article on the industrialization of our “à la carte” services.

Are you too looking for an SSO solution for your digital services, but don’t know which software to try out first? Well, we’ve wasted a lot of time on the question, so you’ll be able to benefit from our feedback!

SSO (Single Sign-On) is the tool we wanted to setup in order to centralize authentication across all our tools via a single platform, so that users would only have to log in once, with a single account, to access services; just like a Google account that gives access to all Google services (Drive, Docs, Forms, Calendar…).

It emerges from a need we’ve had since 2019 with our members: once their account has been created on the member area, our members then still have to create an account on Nextcloud, then again a new account on Gitea… a long and off-putting procedure in short.

We had put in place a number of features to facilitate the creation of these accounts, but it was essentially fiddling with the software’s administration API; in short, the compromise was unsatisfactory, and deterred us from adding new services for a long time.

So, after a few years in operation, we set out to find SSO solutions.

🔗Warning: we don’t have all the answers!

This article is not intended to be a repository of free SSOs. It reflects our own research experience and represents the groundwork that we collectively carried out since early 2023. We took more than a year to test, contribute, improve and then choose our solution.

Some solutions have improved since our tests, and have integrated features that were important to us and weren’t there when we tested the software. We will not be updating this article as these solutions improve.

If, however, you feel that having an updated comparison of free SSOs would be relevant, we encourage you to create your own SSO comparison sheet which will undoubtedly be of great help to structures looking for them; feel free to use our feedback as a basis for this.

And finally, we’re writing this article with the obvious biases of the young innovative solutions enthusiasts that we are:

• a penchant for sobriety (memory, CPU) ;
• not too keen on maintaining an LDAP directory;
• an appetite for modern, streamlined graphical interfaces;
• and a small preference for modern languages (Go, Rust…) over older ones (Java, Perl), without this weighing too heavily in our judgment, and without wishing to reignite a language war.

We don’t claim to be impartial, so please take our feedback with a grain of salt!

🔗Our criteria

We had a pretty clear idea of what we wanted, which is perhaps why the search turned out to be so inconclusive.

Our major constraints:

• The solution must of course be free and open-source: this eliminates a good number of options, starting with Microsoft Active Directory and Okta/Auth0.
• It must be possible to import our existing database: the passwords in our initial database are hashed with bcrypt, and we don’t want to ask all our members to reset their passwords;
• The solution must support the OpenID Connect (OIDC) protocol as a provider, not necessarily as a client. We want to authenticate all our tools via OIDC.
• The software must be actively maintained or developed;
• The memory footprint of the solution must be small:
• no more CPU than a simple web application;
• no more than 500 MB RAM for SSO and OIDC support, and ideally less than 150 MB.

Our secondary constraints:

• Complete management of the authentication workflow: login, forgotten password, change of e-mail address and username;
• Complete registration workflow: account creation, e-mail address validation, open-source captcha ;
• Two-factor authentication (TOTP);
• Works autonomously with its own database: does not require LDAP (PostgreSQL works for us);
• Translates at least into English and French ;
• System of permissions / access restriction to certain services based on group membership: for example, users in an “admin” group would connect to certain services inaccessible to others.

Our bonuses:

• Customizable fields at registration: fields can be added for each user, and some can be deactivated (notably first and last name fields).
• Integrated (but deactivatable) member area with customizable options: access portal to services, possibility of displaying membership status with customized code snippets…
• Works in total autonomy: a single container for everything, or in a pinch two containers: one for SSO and one for OIDC, for example. The database can be separated as well.

We’ll see later that some secondary constraints became primary ones, and other major criteria were ultimately de-prioritized.

🔗In-house software

At the outset, we briefly considered the idea of developing in-house software dedicated to authentication. We have some knowledge of Rust, several projects using the Actix web framework and authentication requires relatively few web pages to be designed - we could have started with our own tool.

But two caveats made us change our minds…

OpenID Connect handling. There’s a Rust package for creating an OIDC server called oxide-auth, but it’s not under active development and lacks crucial OIDC protocol features; in short, it’s rather incomplete and poorly maintained. We could have re-implemented OIDC ourselves, but that would have meant an additional workload.

The authentication and registration flows. As we formalized our criteria, we realized that writing this tool would be quite complex if we wanted it to be complete: registration requires sending a confirmation e-mail, authentication might require implementing TOTP, we might want to implement a captcha… add to that localization (translation), management of forgotten passwords, permissions… and it’s getting to be a lot for our shoulders.

🔗Keycloak

We already knew Keycloak - it’s the best-known open-source solution when it comes to SSO. We can’t miss it.

A leader in its field, Keycloak is an all-in-one solution, supports all essential standards, is packed with features… But that’s also one of its shortcomings: there are so many features in the software that it becomes a gas factory. But that didn’t stop us from trying out the tool.

In 2023, we tested Keycloak in version 22.0.1, with the official Docker image weighing in at 441 MB - far too much for our liking.

Starting a Keycloak development instance (based on the instructions given on the README) sets the tone:

NAME       CPU %   MEM USAGE / LIMIT   NET I/O       BLOCK I/O       PIDS
keycloak   0.64%   469.3MiB / 800MiB   1.05kB / 0B   165MB / 179MB   45

Barely launched, the container already consumes 470MB of RAM, which seems outrageously high to us.

The software is written in Java, and that didn’t appeal to us at all. We wanted a lightweight solution, in a modern language, with just enough functionality for our needs. Keycloak is the exact opposite of that description.

So we set out to find alternatives to Keycloak… and at the end of the article we’ll explain why we finally reverted to this choice.

Criteria	Keycloak
Free / open-source	✅ Apache 2.0
Lightweight (RAM)	❌ approx. 500 MB
Lightweight (image)	❌ approx. 500 MB
Lightweight (CPU)	✅ Pretty much OK
OIDC support	✅
Reliable backend other than LDAP	✅
bcrypt password support	✅
Login form	✅
Registration form	✅
Validation by mail	✅
Password recovery	✅
2FA TOTP	✅
Open-source captcha	❌ No open-source captcha
Localization (FR/EN)	✅
CSS customization	✅ To some extent…
RBAC (permissions)	⚠️ Does not restrict access to apps
Integrated member area	✅
Simple to deploy	✅
Customizable fields	✅ Highly customizable
Active development	✅
Software reputation	✅ 23.6k stars, leader
Language	❌ Java

🔗Authelia

We quickly found Authelia.

Written in Go - a modern, disruptive language - the software consumes less than a hundred MB in RAM. Its Docker image weighs in at just 20 MB, and its beautiful design and light weight are highly appreciated.

Despite this, we have identified two blocking factors…

It requires an LDAP directory. Despite its air of modernity, Authelia supports only two types of database for authenticating users:

• LDAP, for which OpenLDAP can be used, but which our reluctance to maintain an LDAP directory prevents us from choosing;
• a YAML configuration file, in which users are added manually (which is handy for testing, but not at all for production).

No registration form. To create an account, an admin must intervene, and accounts cannot be created by users on their own. There isn’t even an administration interface, you have to modify the LDAP or the YAML file.

But we persisted with Authelia. In April 2023, we came up with the crazy idea of creating a small software program to serve as a registration form and administration interface, which would add and modify entries in the YAML file of the users we planned to use in production. Denise and Monique were on the project, but we ended up abandoning this rather convoluted idea.

We also observed in the responses to the project’s tickets that developers are very reluctant to accept modifications to their code (in particular, authentication backends other than LDAP) “for security reasons”, leaving us little room for contribution should the need arise.

Criteria	Authelia
Free / open-source	✅ Apache 2.0
Lightweight (RAM)	✅ Less than 100 MB
Lightweight (image)	✅ Less than 50 MB
Lightweight (CPU)	✅ Fast and sober
OIDC support	✅
Reliable backend other than LDAP	❌ YAML doesn’t count!
bcrypt password support	✅
Login form	✅
Registration form	❌
Validation by mail	✅
Password recovery	✅
2FA TOTP	✅ WebAuthn too
Open-source captcha	❌ No captcha
Localization (FR/EN)	✅ Yes
CSS customization	❌ Requires binary recompilation
RBAC (permissions)	✅ Yes
Integrated member area	❌
Easy to deploy	✅
Customizable fields	❌
Active development	✅
Software reputation	✅ 21.8k stars
Language	✅ Go

🔗Authentik

Authentik stood out in our searches, notably because it compares itself ostensibly to Keycloak and Authelia on its homepage, boasting its many features.

And there’s a lot to like: this SSO solution features a account creation form and even seems to be able to dispense with an LDAP directory altogether, using its own database. It also makes it fairly easy to modify the pages served - adding CSS sheets is very straightforward.

Written in Python, this program seemed to have everything to please. The only drawback at first glance is that it integrates a captcha system, but only supports proprietary captchas (hCaptcha, reCAPTCHA…). We might consider developing our own integration if the need arises.

We have therefore tried to set it up. Installation requires a PostgreSQL database and a Redis cache. It is necessarily deployed in two containers: a server and a worker.

The size of the ghcr.io/goauthentik/server Docker image is initially rather surprising: 802 MB in its 2023.6.1 version, making you wonder what could be taking up so much space inside.

Deployment then reveals Authentik’s true nature:

NAME               CPU %     MEM USAGE / LIMIT    NET I/O           BLOCK I/O         PIDS
authentik-worker   0.05%     401.8MiB / 500MiB    582kB / 516kB     115kB / 0B        9
authentik-server   1.11%     473.2MiB / 500MiB    390kB / 244kB     25.2MB / 0B       21
authentik-redis    0.27%     4.258MiB / 300MiB    8.58MB / 3.54MB   4.71MB / 86kB     5

Despite the RAM limit of 500MB on both containers, they each reserve a minimum of 400MB of RAM upon launch: the containers have just been restarted and no web page has yet been consulted.

It’s a great example to show that an application can be greedy without being written in Java: this software consumes at least twice as many resources as Keycloak.

Criteria	Authentik
Free / open-source	✅ MIT (for the free version)
Lightweight (RAM)	❌ 800+ MB idle: monstrous
Lightweight (image)	❌ 800 MB: mammoth
Lightweight (CPU)	❓ Not tested
OIDC support	✅
Backend other than LDAP	✅ PostgreSQL
bcrypt password support	❓ Untested
Login form	✅
Registration form	✅
Validation by mail	✅
Password recovery	✅
2FA TOTP	✅
Open-source captcha	❌ reCaptcha / hCaptcha
Localization (FR/EN)	✅
CSS customization	✅
RBAC (permissions)	✅
Integrated member area	❓
Simple to deploy	✅
Customizable fields	❓
Active development	✅
Software reputation	✅ 13.6k stars
Language	✅ Python

🔗Ory

Another popular solution is called Ory, with its components Hydra and Kratos.

Written in Go and incorporating a registration form, it looks naturally attractive… until it’s time to deploy it locally.

Denise, a member of our Contribution Committee, has deployed a functional instance of the software. Its RAM consumption is quite low.

It requires four containers:

• ory-kratos, the identity server, which manages the user directory and interfaces with the PostgreSQL database (which you’ll need one more container for).
• ory-kratos-ui, the identity server’s graphical interface.
• ory-hydra, the OpenID Connect module that uses Kratos as an authentication backend.
• ory-hydra-consent, the Hydra module that displays an interface to request user consent when accessing an application.

Setting up these containers is a pain, Denise had to recompile each module and rewrite a Dockerfile to achieve a working configuration. The configuration files are not easy to get to grips with (especially the identity file).

And here’s the icing on the cake: at the time of testing, it was not possible to translate the software without forking another module, ory/elements.

In short: even if it consumes few resources, this solution is a real gas factory, and it would seem that the whole installation procedure is there to dissuade us from self-hosting it and going for the paid solution, hosted by the company. This is the conclusion we came to in March 2023.

Criteria	Ory / Kratos / Hydra
Free / open-source	✅ Yes (for the free version)
Lightweight (RAM)	✅ Yes (less than 150 MB)
Lightweight (image)	✅
Lightweight (CPU)	✅
OIDC support	✅
Backend other than LDAP	✅
bcrypt password support	✅
Login form	✅
Registration form	✅
Validation by mail	✅
Password recovery	✅
2FA TOTP	✅
Open-source captcha	❌ No captcha
Localization (FR/EN)	❌ Not available at time of testing
CSS customization	❌ Recompilation required
RBAC (permissions)	❓
Integrated member area	✅
Simple to deploy	❌ Hell on Earth
Customizable fields	✅
Active development	✅
Software reputation	✅ 15.6k stars
Language	✅ Go

🔗Casdoor

During our research, we came across the awesome-auth page, which lists open-source authentication solutions. Casdoor is systematically listed first in many categories.

We quickly realized that Casdoor, an open-source SSO, is a related project to Casbin, and that the developers of both are the owners of the awesome-auth repository. They have therefore positioned themselves as the first alternative everywhere, to promote their solution…

Despite what we consider to be a lack of honesty on their part, we gave their solution a try. Their documentation is rather poorly written, apparently badly translated from Chinese, which caused us some difficulty in configuring Casdoor.

But once configured, the software was a dream: it had almost all the functionality we needed! And the missing solutions seemed easy to integrate, as the software is highly modular.

The software’s RAM consumption is negligible, and some particularly interesting features not found elsewhere were well thought-out (integrated payments, multi-organization management, etc.). New versions are frequent, and the added features are relevant.

Neil even ended up presenting Casdoor at Camp CHATONS 2023 as an excellent solution.

Among the things missing:

• The French translation was very bad (Home translated as Maison (house) rather than Accueil (welcome page)…), which is why we mobilized to contribute to the translation on their Crowdin.
• There’s a free captcha, but it’s not very secure; we wanted to integrate mCaptcha by contributing to the code, which seemed rather accessible as the code is very modular and their software already supports many captchas.

Then, little by little, we began to discover the negative points of this solution.

The first negative point: new versions are far too frequent. There is generally one new version per commit. Versioning is chaotic, not a semantic versioning but a somewhat abstract variant that doesn’t seem to make much sense.

In three months, the software changes so much that there’s a lot of reconfiguration work to be done, and updates break the installation quite regularly.

In addition, we identified several security problems with Casdoor, starting with its password retention policy: the software supports numerous password derivation algorithms (including bcrypt), but stores passwords in clear text by default, at the time of our tests.

On the other hand, Casdoor disseminates a lot of information through its API, sometimes sensitive information. Hannaeko, a member of our Contribution Committee, spotted a rather serious flaw: the response of all the software’s capatchas is disclosed via the API…

The bug was solved a month and a half later, but we had already decided on another solution, as we weren’t entirely convinced by the quality of the code and the features stability.

Criteria	Casdoor
Free / open-source	✅ Yes (for the free version)
Lightweight (RAM)	✅ Yes (less than 150 MB)
Lightweight (image)	✅ Yes (45 MB)
Lightweight (CPU)	✅
OIDC support	✅
Backend other than LDAP	✅
bcrypt password support	✅
Login form	✅
Registration form	✅
Validation by mail	✅
Password recovery	✅
2FA TOTP	✅
Open-source captcha	✅ Yes, but easy to break
Localization (FR/EN)	⚠️ Yes, but needs work
CSS customization	✅
RBAC (permissions)	✅ Quite complex to set up
Integrated member area	✅
Simple to deploy	✅ Yes, despite poor documentation
Customizable fields	✅
Active development	⚠️ Yes, but release of new versions is chaotic
Software reputation	✅ 10.2k stars
Language	✅ Go
Blocking points	❌ Security taken lightly, little stability between updates

🔗Zitadel

We also tested Zitadel, which presents itself as an emerging alternative to other SSOs and seems to be improving (very slowly) over time.

Very good points: it integrates a registration form and works with PostgreSQL, and it’s relatively lightweight.

What put us off using it: the lack of customization of user fields (first and last name mandatory) and the total absence of captcha support.

For customizable fields, a ticket has been open since 2023 and will no doubt be resolved by the time Zitadel V3 is released, but it’s always the same: you never know when it’s going to come out, it’s impossible to plan ahead, and in the meantime the functionality isn’t there.

Criteria	Zitadel
Free / open-source	✅ Apache 2.0
Lightweight (RAM)	✅
Lightweight (image)	✅ 130 MB
Lightweight (CPU)	✅
OIDC support	✅
Backend other than LDAP	✅ PostgreSQL
bcrypt password support	✅
Login form	✅
Registration form	✅
Validation by mail	✅
Password recovery	✅
2FA TOTP	✅
Open-source captcha	❌ No captcha
Localization (FR/EN)	✅ Yes
CSS customization	✅
RBAC (permissions)	❓
Integrated member area	❓
Simple to deploy	✅
Customizable fields	❌ Not so much (1), (2)
Active development	✅
Software reputation	✅ 9k stars
Language	✅ Go

For the following softwares, we can’t provide you with a summary table because we haven’t tested them sufficiently, or it’s been too long since we tested them.

🔗Canaille

Canaille is a small software program developed by a member of the CHATONS collective, Yaal Coop (the CHATONS member in question being Nubla, developed by this cooperative).

Canaille is written in Python and uses a LDAP backend, but it seems to have recently integrated support for a SQL backend.

Initially, the software didn’t integrate a registration form, and this was a sticking point for us. So Denise tried to directly contribute to the code to add this functionality, but the implementation wasn’t entirely satisfactory to the developers who first wanted to add other features that might depend on it.

To avoid creating further inertia in our research, we moved on and tested other solutions.

Today, Canaille seems to have integrated the registration form and could be a decent potential solution, but seems to be struggling to find its community and audience.

🔗LemonLDAP

We haven’t tested LemonLDAP, but it’s a commonly suggested solution.

It’s an OpenID Connect server that uses an integrated LDAP directory. It has many interesting features, including the account creation form and an open-source captcha. The software seems to have been created in 2006 and is maintained by French people.

The fact that it’s written in Perl and works with LDAP was a bit of a turn-off, however. It wasn’t necessarily a deal-breaker, but the fact remains that we ended up testing other solutions because we had limited time and couldn’t test all the software; we didn’t linger on this one.

🔗SSOwat

SSOwat is the authentication solution integrated into the Yunohost project, which we examined very briefly and then quickly dismissed.

It’s a Nginx extension written in Lua and uses an LDAP backend.

As it happens, its operation is rather intrinsically linked to Yunohost, and it seems rather difficult to detach it from Yunohost - all the more so as we use Caddy, and not Nginx, as reverse-proxy for our services.

The software has changed quite a bit with the version 12 of Yunohost; the SSO module has been broken down into three separate modules, yet it doesn’t make it any easier to install in environments other than Yunohost itself.

It remains a viable solution, provided that your infrastructure runs entirely under Yunohost.

🔗Rauthy

In the nice little projects category, we looked at Rauthy, an SSO written in Rust.

The software seems to have a number of features we needed, including the registration form. It depends on a PostgreSQL backend.

It has the advantage of being extremely light and fast. For an SSO, it’s very sober and efficient.

That said, the project is still far too young for our taste: maintained by a single person, not fully mature in terms of design and functionality, it’s still a bit of a wobbly solution, although it’s improving year on year.

The software has no community (yet), so very little support and feedback too, and this inevitably works against it in the balance.

🔗Hiboo

Always keen on experimental projects, we took a look at the CHATONS TeDomum project Hiboo.

We’re not the first to have thought of reinventing the wheel: TeDomum presents Hiboo in 2019 and tries to adapt unified authentication methods to their own taste.

The project, written in Python, is experimental but generally functional according to TeDomum, which uses it in production.

At the end of 2023, TeDomum’s developers took stock of this experimentation and considered two options :

1. to abandon the development of Hiboo and to prepare to migrate their database towards alternatives (Authelia, Keycloak, Authentik);
2. to give themselves the means to have a sustainable development model: have an active community, pay a dev…

Here ends our follow-up of the project, but it still seems to be alive and kicking. You can consult their repository to find out more.

🔗Finally… Keycloak

Our research began with Keycloak, and ends with Keycloak. It was well worth it…

It’s our fallback solution, which isn’t really that bad because it’s extremely widespread, which gives us a major advantage: if we run into a problem, we can be pretty sure that someone else has already run into it and that there’s a solution.

Regarding RAM consumption: we’ve found, and corroborated with other testimonials, that although Keycloak consumes an irreducible minimum 500 MB of RAM, it doesn’t seem to go much further:

With a limit of 1 GB RAM, the software should run smoothly and consume fairly little CPU on average. 1 GB is really a lot for us (a quarter of RAM for most of our machines…), but we eventually accepted this painful compromise.

But that wasn’t the only sacrifice we had to accept.

🔗A missing cog: the captcha

We can’t yet deploy Keycloak as a replacement for our member area while we develop a captcha for Keycloak, a protection tool that we feel is absolutely essential to protect our service.

Currently, Keycloak officially supports reCaptcha (Google), and the community has developed a plugin to support hCaptcha (Cloudflare). We’d like to add support for mCaptcha (poorly maintained, but that’s our solution for now), which would require us to code a plugin in Java.

Without this brick, we use Keycloak only for our digital support program, since they don’t include an account creation form. We’ll be able to use it to replace our member area once this brick has been written.

🔗The vain multi-realm hope

A “realm” is a Keycloak term for an environment in which an organization can create its own applications, have its own users, its own groups…

Keycloak allows you to create several realms, which means you can host many different organizations, each with their own applications and users. This is useful for providing services to many different organizations.

But the biggest advantage of this approach is also its biggest drawback: applications and users cannot be shared between several realms.

For example, if a person is a member of the organization “The Beta”, but also of the organization “Maison des Peuples et de la Paix”, they will have to create two different accounts to access the services of these respective organizations. And if they become a member of La Contre-Voie, they’ll need a third account. What’s the point of having unified authentication if you have to create multiple accounts per person on it?

But perhaps the most problematic issue is for applications: let’s imagine we wanted to make available a service shared by all organizations, for example a videoconferencing tool or a pad service… how should we proceed in this environment?

The answer is simple: we’d need to deploy as many instances of this tool as there are existing realms, because almost all software that supports OpenID Connect can only connect to one OIDC server per instance. However, in this particular use case, this would be a huge waste of resources.

We therefore decided - halfway down the road - to host everyone in a single realm.

🔗Less autonomy for organizations

Having everyone in the same realm imposes a serious constraint: management of members by third parties (e.g. administrators among the structures we host) is no longer possible.

When each organization has its own realm, we have no problem giving Keycloak administration rights to managers within these organizations, as these rights are partitioned within their realm. A “referent” person could thus add, modify or delete members independently, and even give or withdraw access rights for services within their organization, without asking us.

If everyone is in the same realm, giving administration rights to a referent means giving them rights over all the organizations we host, including our users, which is absolutely unthinkable.

For the time being, the palliative solution we’ve chosen is to ask each organization to send us an e-mail with the list of members who are supposed to have access to their services, with their respective rights, each time this list is modified… then we transfer this list to production ourselves. We’re not going to tell you about the support work involved…

Eventually (and fairly quickly), we’ll probably have to design a middleware that will act as an interface between the referent members of each organization and the Keycloak administration API, enabling them to manage their members and their rights in a controlled and restricted way.

🔗No access rights management in Keycloak

Incredible as it may seem, Keycloak doesn’t allow you to manage access rights to an application for certain users or groups. All members of a realm have access to all applications.

Keycloak’s developers have decided that this is not part of the software’s scope, because Keycloak only handles authentication, not authorization (1), (2); that user authorization therefore falls within the application’s role.

There is a plugin for this purpose, but it can be easily bypassed in certain cases and is therefore not a secure solution at all.

However, not all applications can restrict access according to user groups (e.g. a Nextcloud plugin didn’t support this until… last week!), which adds a serious constraint to the selection of applications we offer.

As a rather effective workaround, we use the Caddy plugin caddy-security, which enables us to create an authentication wall on any application within the reverse-proxy, according to the groups/roles assigned to each user.

🔗One last solution for the road…

There is a perfectly valid solution to setup multiple services with OpenID Connect without too much headache: use one of the applications as an authentication provider.

For example, if you are serving Nextcloud, Nextcloud itself can act as an OIDC identity server. The same applies to most well-known applications, such as WordPress. This means that members will use their logins for these applications to connect to other applications.

However, this implies that your members must have an account on the application acting as provider (e.g. Nextcloud or WordPress); this may not always be desirable.

Also, compliance with any other criteria you may have (captcha, group management, organization management, field customization…) can prove rather complicated.

🔗Conclusion

In short: we’ve adopted Keycloak, even if we’re not very happy with it due to missing functionalities and rather restrictive use cases.

But don’t bother suggesting other SSO solutions! Now that we’re on Keycloak, we don’t intend to change just yet, as it’s a very cumbersome and time-consuming operation and we’ve already spent a good two years looking for the ideal solution without finding it.

However, we hope this article will give you a clearer idea of the range of possibilities and make your choice easier! Bear in mind, however, that some of the software we have presented has evolved significantly since we first reviewed it.

For ethical digital service providers, we see unified authentication as a major challenge, for a number of reasons:

The search for convenience. For an uninitiated public, used to the “all-in-one account” from Google, Apple or Microsoft, unified authentication for free services is not disorienting, and offers a level of comfort that will make it much easier to get used to, especially if you offer several different software packages.

Services open without registration are increasingly difficult to maintain. Services like Framaforms are overflowing with spam, shared pads are being used for phishing purposes, even our link shortener is costing us moderation time every week. By the end of 2023, many Jitsi (video conferencing tool) instances had to close due to a surge in unlawful and unethical usage.

We hope this lengthy summary of our research will be useful to some of our readers!

If you think this kind of feedback is valuable, you can support us financially to enable us to continue documenting our work:

Drop your star

and donate to La Contre-Voie !