Nouveau backend d'authentification
Évolution en préparation
Cette page décrit une évolution non livrée. État au 2026-10-11, d'après l'ADR-0125 (acceptée le 2026-09-11), la documentation du backend v0.2, la configuration Keycloak de référence de SenSaaS (décision du 2026-09-30) et la décision du 2026-10-11 sur le backend mutualisé.
En bref
La connexion à la webapp passe par la plateforme d'authentification centralisée que SenSaaS met à disposition. Le backend de la webapp est mutualisé : un seul service, exploité par SenSaaS, pour tous les revendeurs et leurs clients. Les administrateurs des revendeurs n'ont rien à installer, rien à maintenir et rien à migrer. L'utilisateur y gagne la connexion unique entre le portail et la webapp, la connexion par passkey, et plus aucun jeton ne circule dans le navigateur.
Où en est le chantier
| Élément | État d'après la source |
|---|---|
| Choix d'architecture (ADR-0125) | acceptée le 2026-09-11 |
| Configuration de référence de la plateforme d'authentification | arrêtée le 2026-09-30 ; serveur de recette ident.dev.sensaas.fr utilisé pour les essais |
Plateforme d'authentification de production (ident.sensaas.fr) |
installation, sauvegarde et recette à faire (fiche KC-01) |
| Reprise des comptes existants | principe retenu, script d'import à écrire (fiche KC-01) |
| Backend de la webapp | écrit en version 0.2 ; alignement sur la configuration de référence à faire (fiche KC-04) |
| Connecteur v2 | livré le 2026-10-02 : il accepte les jetons de la plateforme, en plus de sa connexion directe |
Pourquoi
Le fonctionnement actuel reproduit celui de la passerelle historique : un jeton conservé par le navigateur, une base locale qui recopie les utilisateurs, les serveurs et les dossiers, une seule instance de service. Trois besoins le rendent caduc :
- la haute disponibilité - plusieurs instances du service derrière un répartiteur de charge, ce qu'une base locale et une session en mémoire interdisent ;
- la connexion unique - impossible en relayant des mots de passe : un fournisseur d'identité ne donne jamais le mot de passe de l'utilisateur à la webapp ;
- un seul point d'exploitation - l'identité et les sessions sont tenues au centre par SenSaaS, pour tous les revendeurs : aucun composant d'authentification à déployer ni à mettre à jour chez un revendeur.
Le principe en une phrase
Le navigateur ne voit jamais un jeton : il porte un cookie de session que le backend seul sait lire, et c'est le backend qui présente le jeton au connecteur. C'est le modèle "Backend-For-Frontend" recommandé pour les applications web.
navigateur (cookie de session)
│
▼
backend SenSaaS mutualisé ──► plateforme d'authentification SenSaaS (connexion, renouvellement, déconnexion)
│ ──► API centrale SenSaaS (à quels connecteurs l'utilisateur a accès)
│ ──► magasin de sessions (la session, partagée entre les instances)
▼
connecteur SenSaaS du client (API v2)
Tout ce qui est au-dessus du connecteur est exploité par SenSaaS. Le connecteur reste installé chez le client et reste seul juge des dossiers, des droits et des filtres.
Ce qui change pour l'utilisateur
- La connexion devient une redirection. Vous ne saisissez plus votre mot de passe dans la webapp : vous êtes envoyé sur la page "Se connecter à SenSaaS" de la plateforme d'authentification (adresse électronique, puis mot de passe ou passkey).
- Connexion unique. Une fois connecté, vous ne vous reconnectez pas pour passer du portail à la webapp.
- Connexion par passkey. Une passkey remplace le mot de passe par la biométrie de l'appareil ; sans passkey, mot de passe et, si vous l'avez activée, double authentification. La connexion par un compte Microsoft ou Google n'est pas prévue au départ : la source la décrit comme un ajout possible plus tard.
- Vos identifiants ne changent pas. Les comptes existants sont repris avec leur mot de passe : l'exigence posée est une reprise transparente, sans adresse à revalider ni profil à compléter.
- Une seule session à la fois. Une connexion ailleurs ferme la plus ancienne (webapp et application comprises), sauf pour les comptes explicitement autorisés à en ouvrir plusieurs.
- Le choix du connecteur devient un écran. Si plusieurs connecteurs vous sont rattachés, la webapp vous les propose ; votre choix est mémorisé dans la session.
- Le compte se gère dans la console de compte de la plateforme : mot de passe, passkeys, double authentification, sessions ouvertes. Les écrans correspondants disparaissent de la webapp.
- Une coupure courte ne vous déconnecte plus. La webapp distingue "votre session est finie, reconnectez-vous" d'"un service est momentanément indisponible, réessayez". Dans le second cas, la session est conservée.
Ce que vous ne verrez pas, et qui compte
Le jeton d'accès quittait le serveur et vivait dans le stockage du navigateur : c'était le point d'entrée d'une attaque par script injecté. Il n'y est plus. C'est le gain de sécurité principal du changement.
Ce qui change pour le revendeur
Rien à installer, rien à maintenir, rien à migrer
La plateforme d'authentification, le backend, le magasin de sessions et l'annuaire des connecteurs sont exploités par SenSaaS : installation, haute disponibilité, sauvegardes, mises à jour, rotation des secrets et supervision sont à sa charge. Le revendeur ne reçoit ni kit à héberger, ni base à reprendre, ni script à lancer.
Ce que le revendeur fait, depuis le portail
Toute entreprise - revendeur comme client - est une organisation de la plateforme d'authentification, rattachée à son revendeur. Depuis le portail, un revendeur :
| Opération | Portée |
|---|---|
| voir ses sous-revendeurs, ses clients et leurs utilisateurs | tout son arbre |
| créer un client (l'organisation et son premier utilisateur) | sous lui directement |
| ajouter un utilisateur, renvoyer son invitation | ses clients directs et sa propre organisation |
| activer ou désactiver un utilisateur | ses clients directs et sa propre organisation |
Un nouvel utilisateur reçoit une invitation par courriel : il choisit son mot de passe et son adresse est vérifiée au passage. Désactiver un utilisateur le déconnecte partout. Un nouveau revendeur est créé par SenSaaS, pas depuis le portail.
Ce qui reste au site du client
Rien de nouveau à configurer pour l'authentification. Deux conditions, déjà couvertes par le connecteur v2 :
- le connecteur doit pouvoir joindre la plateforme d'authentification en HTTPS sortant, pour télécharger ses clés publiques au premier jeton ;
- chaque utilisateur doit exister dans le connecteur avec la même adresse électronique
que son compte SenSaaS : c'est elle qui le relie à ses dossiers. Sinon, le connecteur
répond 403
AUTH.UTILISATEUR_INCONNU. Voir Sécurité du connecteur.
Ce que le connecteur accepte
Le connecteur reconnaît deux émetteurs de jetons, distingués par leur origine :
| Émetteur | Comment on l'obtient | Usage |
|---|---|---|
| la plateforme d'authentification SenSaaS | par la connexion depuis la webapp ou le portail | le chemin normal : connexion unique, comptes gouvernés par SenSaaS |
| le connecteur lui-même (mode direct) | connexion locale par identifiant et mot de passe | réseau local, fonctionnement sans Internet, outils et scripts sur site |
Les deux modes sont toujours actifs en parallèle : la connexion directe n'a pas d'option pour être désactivée. Les deux chemins aboutissent à la même couche d'autorisation.
Pour le chemin central, le connecteur n'émet plus rien : il vérifie la signature du jeton avec les clés publiques de la plateforme, mises en cache et conservées sur disque - donc sans appel réseau à chaque requête, et même après un redémarrage sans Internet.
Les réglages qui ont une conséquence visible
- Jeton d'accès : 15 minutes, renouvelé automatiquement par le backend. Un compte désactivé perd l'accès au plus tard à l'expiration de son jeton.
- Session : 7 jours sans usage, 30 jours au plus, sans session hors ligne.
- Jeton de renouvellement à usage unique. C'est ce qui rend indispensable le verrou partagé du backend : plusieurs instances qui renouvelleraient en parallèle détruiraient la session.
Ce qu'on perd, et qui est assumé
- C'est une porte à sens unique. Sans base locale ni connexion par mot de passe dans la webapp, revenir au modèle précédent exigerait de reprovisionner les utilisateurs.
- La plateforme d'authentification devient critique : indisponible, il n'y a plus ni connexion ni renouvellement. Sa haute disponibilité, et celle de sa base, sont à la charge de SenSaaS.
- Le magasin de sessions est un seul nœud en version 0.2, qui redémarre en quelques secondes et retrouve ses sessions grâce à son journal. L'étape suivante est une réplique et une surveillance automatique.
Questions fréquentes
Le revendeur doit-il migrer quelque chose ?
Non. Le backend est mutualisé et exploité par SenSaaS ; les comptes existants sont repris par SenSaaS. Voir Bascule v0.1 vers v0.2.
Perd-on la possibilité de se connecter sans Internet ?
Non : la connexion directe au connecteur est conservée, toujours active.
Que se passe-t-il quand on retire un accès à un utilisateur ?
Le désactiver depuis le portail déclenche sa déconnexion centrale, qui purge sa session. L'application perd l'accès au plus tard à l'expiration de son jeton (15 minutes).