Auth0 ou Keycloak : quelle solution SSO pour votre application ?

Toute application un peu sérieuse a besoin d'authentification : connexion, gestion des rôles, parfois SSO d'entreprise. Trois options reviennent, Auth0, Keycloak, et la solution intégrée de votre base. Le choix se joue sur la souveraineté et l'effort d'exploitation.

Auth0 : managé, rapide à intégrer

Auth0 est un service d'authentification clé en main : connexion sociale, SSO, MFA, gestion des utilisateurs, sans serveur à gérer. On l'intègre vite, c'est robuste, et ça couvre des besoins entreprise complexes (SAML, OIDC). La contrepartie : un SaaS payant qui grimpe avec le nombre d'utilisateurs actifs, et vos identités vivent chez un tiers américain.

Le modèle économique mérite d’être posé tôt, parce qu’il est la principale raison des migrations vers une alternative. D’après la grille tarifaire d’Auth0, la facturation suit le nombre d’utilisateurs actifs mensuels : le palier gratuit couvre jusqu’à 25 000 utilisateurs actifs, puis les offres payantes démarrent à 35 $ par mois pour 500 utilisateurs en B2C et 150 $ en B2B, avec une progression par paliers, et une facturation au palier supérieur si votre volume tombe entre deux. Certaines fonctions courantes en entreprise, comme les connexions SSO d’entreprise ou le MFA avancé, relèvent d’options supplémentaires. Le coût d’Auth0 suit donc le succès du produit, ce qui est confortable au départ et devient un poste à surveiller.

Keycloak : open source et souverain

Keycloak fait globalement la même chose, SSO, fédération d'identités, SAML, OIDC, rôles fins, mais il est open source et auto-hébergeable. Vos identités restent sur votre infrastructure. C'est le choix de la souveraineté, au prix d'une brique de plus à exploiter (mises à jour, haute disponibilité).

Le contraste est net sur les deux points qui comptent. Keycloak est publié sous licence Apache 2.0, une licence open source au sens de l’Open Source Initiative, sans restriction d’usage commercial, et le projet est hébergé par la Cloud Native Computing Foundation. Il implémente OpenID Connect et SAML, gère la fédération d’identités, les rôles fins et le SSO. Aucun coût par utilisateur : la dépense passe de la licence à l’exploitation, serveur, base de données, montées de version, disponibilité, sauvegardes. L’arbitrage n’est donc pas « payant contre gratuit » mais « coût prévisible externalisé contre charge d’exploitation interne ».

Et Supabase Auth ?

Pour beaucoup d'applications, l'authentification intégrée de Supabase (JWT, rôles via RLS, providers multiples) suffit, sans ajouter ni Auth0 ni Keycloak. On y vient par défaut sur nos projets, voir Agence Supabase.

Cette option mérite d’être détaillée, car elle suffit dans plus de cas qu’on ne le croit. L’authentification de Supabase délivre un JWT contenant l’identifiant de l’utilisateur, que la base exploite ensuite directement : les droits s’écrivent en politiques Row Level Security, appliquées par PostgreSQL lui-même, ligne par ligne, quel que soit le client qui interroge. C’est l’avantage structurel, les règles ne dépendent pas de l’application, et le piège en même temps : une table sans RLS activée est lisible depuis le navigateur avec la clé publique. La vérification tient en une requête faite avec la clé anonyme, et elle devrait figurer dans toute recette.

Comment choisir

• Supabase Auth pour la plupart des applications : intégré, simple, suffisant.
• Auth0 si vous voulez du managé, des besoins SSO entreprise riches, sans contrainte de souveraineté forte.
• Keycloak dès que les identités doivent rester chez vous (souveraineté, secteur sensible).

Le bon choix se fait au cadrage, selon votre contexte SSO existant, un sujet qu'on traite sur nos projets de développement d'applications et de SaaS.

Un besoin d'authentification ou de SSO à arbitrer ? Parlons-en.