Authentification multi-tenant : sécuriser votre SaaS sans complexité

Quand vous lancez un logiciel SaaS, l'authentification n'est pas qu'une question de mot de passe. C'est le pilier qui garantit à chaque client que ses données restent isolées, sécurisées, et inaccessibles aux autres utilisateurs de votre plateforme. Or, beaucoup de TPE/PME découvrent trop tard que leur système d'authentification initial ne scalpe pas correctement avec la croissance. Cet article vous explique les patterns éprouvés pour une authentification multi-tenant robuste, sans vous transformer en expert en cryptographie.

Pourquoi l'authentification multi-tenant est différente

Dans une application classique (une seule entreprise cliente), l'authentification vérifie l'identité d'un utilisateur et lui donne accès à toutes les données. Terminé.

Avec un SaaS multi-tenant, vous gérez des dizaines, centaines, ou milliers de clients. Chaque client est un « tenant » isolé. L'enjeu : un utilisateur du Tenant A ne doit jamais voir les données du Tenant B, même s'il force l'URL ou manipule son token. Cela signifie que chaque requête authentifiée doit embarquer non seulement l'identité de l'utilisateur, mais aussi son tenant d'appartenance. Et votre serveur doit vérifier cette appartenance à chaque fois.

C'est une couche supplémentaire qui, si elle est mal implémentée, devient un cauchemar de sécurité.

JWT avec contexte tenant : le standard de facto

Le JWT (JSON Web Token) est devenu le standard pour les SaaS modernes. Au lieu de stocker une session côté serveur (lourd), vous signez un token contenant les informations clés de l'utilisateur. Le navigateur ou l'app mobile le renvoie à chaque requête.

Pour le multi-tenant, le JWT doit contenir :

• user_id : l'identifiant unique de l'utilisateur
• tenant_id : le tenant auquel appartient cet utilisateur
• roles/permissions : ce qu'il peut faire au sein du tenant (optionnel mais recommandé)
• exp : la date d'expiration du token

La signature du JWT (à base d'une clé secrète côté serveur) empêche l'utilisateur de modifier ces données sans que vous le détectiez.

Exemple simplifié en pseudocode : Un utilisateur Alice du Tenant Acme se connecte. Votre API valide ses identifiants, puis génère un JWT contenant {user_id: "alice_123", tenant_id: "acme_456", exp: demain}. Alice stock ce token en local. À chaque requête, elle l'envoie. Votre API le vérifie, extrait le tenant_id, et s'assure que toute requête est filtrée sur ce tenant. Alice ne peut accéder qu'aux données où tenant_id = "acme_456".

Isolation des données : le vrai travail

Un token bien formé, c'est bien. Mais l'isolation réelle se fait au niveau base de données. Chaque requête doit filtrer les résultats sur le tenant_id embarqué dans le JWT.

Vous avez deux architectures principales :

Une base de données partagée (la plus couante en TPE/PME)

Toutes les données de tous les clients vivent dans la même base. Chaque table a une colonne tenant_id. À chaque requête, vous ajoutez automatiquement un filtre WHERE tenant_id = ? en utilisant la valeur extraite du JWT. Un ORM moderne (Sequelize, Prisma, SQLAlchemy) peut automatiser cela via un middleware de contexte.

Avantage : Simple à mettre en place, coûts serveur bas. Inconvénient : Si quelqu'un buggue le filtre, tous les clients sont exposés. Nécessite des tests rigoureux.

Bases de données ségrégées (plus sécurisé, mais plus coûteux)

Chaque tenant a sa propre base de données. L'authentification révèle la chaîne de connexion du tenant, ce qui isole nativement les données. Vous devez gérer une « base de métadonnées » qui mappe les tenants à leurs connexions.

Avantage : Isolation garantie, plus facile de respecter les règles de conformité (RGPD, souveraineté des données). Inconvénient : Complexe à gérer, coûts serveur importants, migrations plus lentes.

Pour la plupart des PME qui démarrent, la base partagée avec filtrage strict est le bon choix.

Refresh tokens et renouvellement sécurisé

Les JWT ont généralement une durée de vie courte (15 minutes à 1 heure). Pour ne pas forcer l'utilisateur à se reconnecter toutes les heures, vous utilisez un refresh token : un token de longue durée (quelques jours) stocké en base de données, qui permet d'obtenir un nouveau JWT.

En multi-tenant, stockez aussi le tenant_id avec le refresh token. Si quelqu'un vole un refresh token d'un tenant, il ne peut l'utiliser que pour ce tenant.

Conseil : les refresh tokens doivent être stockés en base, pas en JWT. Cela vous permet de les révoquer instantanément (par exemple, si un utilisateur se déconnecte d'un appareil).

OAuth2 avec tenant : déléguer l'authentification

Si vous acceptez les authentifications sociales (« Se connecter avec Google » ou un SSO d'entreprise), vous devez chaîner OAuth2 avec votre système multi-tenant.

Le flux : l'utilisateur clique « Se connecter avec Google ». Google renvoie son email et un identifiant unique. Vous vérifiez s'il existe déjà dans votre système. S'il est nouveau, vous devez lui assigner un tenant : soit créer un tenant personnel, soit le rattacher à un tenant existant si vous avez un système d'invitations.

Encore une fois, le tenant_id doit figurer dans le JWT que vous générez après ce flux OAuth.

Tests de sécurité : ne pas sauter cette étape

Avant de mettre un SaaS multi-tenant en production, testez agressivement :

• Un utilisateur du Tenant A peut-il deviner et accéder à un ID du Tenant B en modifiant l'URL ?
• Si on rejette un JWT expiré, le serveur répond-il correctement sans leaker d'infos ?
• Les refresh tokens révoqués sont-ils bien bloqués ?
• Un attaquant peut-il forcer un JWT avec un tenant_id différent de celui attendu ?

Ces tests doivent être automatisés dans votre pipeline CI/CD. Un seul bug d'isolation tenant est un incident critique.

Si vous reprenez ou évoluez un SaaS existant, un audit de sécurité des authentifications vaut vraiment le coup.

Intégration avec Dolibarr ou WooCommerce

Si vous construisez un module Dolibarr multi-tenant ou un plugin WooCommerce SaaS, vous devez adapter ce pattern à leurs modèles existants. Dolibarr gère déjà une notion d'utilisateurs et de permissions ; il s'agit de la compléter avec votre couche tenant.

Conclusion : la sécurité commence ici

L'authentification multi-tenant n'est pas sexy, mais elle est le fondement sur lequel repose la confiance de vos clients. Mal fichue, aucune autre optimisation d'IA ou d'automatisation ne sauvera votre crédibilité.

Si vous avez un SaaS à lancer ou à sécuriser, commencez par ce sujet. Testez. Documentez. Et si vous êtes seul(e) face à la question, parlons-en : c'est une fondation qui se construit bien une seule fois.

Questions fréquentes