Nouveau backend d'authentification¶

Évolution en préparation

Cette page décrit une évolution non livrée. État au 2026-09-11, d'après l'ADR-0125 « Le backend est un BFF OIDC Keycloak sans base, avec sessions partagées dans Valkey » (acceptée le 2026-09-11) et la documentation du backend v0.2.

En bref

L'application change de façon de vous connecter : l'identité est gérée par un serveur d'authentification central, la page de connexion n'est plus un formulaire de l'application, et aucun jeton ne circule plus dans le navigateur. Vous gagnez la connexion unique et la connexion par compte Microsoft, Google ou Apple.

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 à l'application ;
un kit hébergeable par un revendeur sans que SenSaaS perde la maîtrise de l'identité : la donnée reste chez le revendeur, les comptes restent gouvernés au centre.

Le connecteur v2, lui, sait déjà faire sa part : il applique l'autorisation des dossiers et sait valider un jeton signé sans appeler personne à chaque requête.

Le principe en une phrase¶

Le navigateur ne voit jamais un jeton : il porte un cookie de session que le serveur seul sait lire, et c'est le serveur 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 ──► serveur d'identité   (connexion, renouvellement, déconnexion)
      │           ──► portail              (quels connecteurs pour cet utilisateur)
      │           ──► magasin de sessions  (la session, partagée entre les instances)
      ▼
  connecteur SenSaaS (API v2)

Ce qui change pour l'utilisateur¶

La connexion devient une redirection. Vous ne saisissez plus votre mot de passe dans l'application : vous êtes envoyé sur la page du serveur d'identité, qui peut être habillée aux couleurs de votre prestataire.
Connexion unique (SSO). Une fois connecté, vous ne vous reconnectez pas pour passer du portail à l'application. Des boutons permettent d'utiliser un compte Microsoft, Google ou Apple si votre organisation l'autorise.
Un seul appareil connecté à la fois. Une nouvelle connexion ailleurs met fin à la précédente : la session d'avant reçoit une demande de reconnexion à sa requête suivante.
Le choix du connecteur devient un écran. Si plusieurs connecteurs vous sont rattachés, l'application vous les propose ; votre choix est mémorisé dans la session.
Le compte se gère ailleurs. Changement de mot de passe, réinitialisation, vérification d'adresse : tout passe par la console de compte du serveur d'identité. Les écrans correspondants disparaissent de l'application.
Une coupure courte ne vous déconnecte plus. L'application distingue désormais « votre session est finie, reconnectez-vous » d'« un service est momentanément indisponible, réessayez dans une seconde ». 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 l'administrateur¶

Ce qu'il faut mettre en place¶

Élément	Rôle	Points d'attention
Serveur d'identité (Keycloak)	comptes, connexion, connexion unique, fédération vers l'annuaire du client	en grappe de deux nœuds ; sa base de données est la vraie ressource critique
*Un domaine (realm) par population*	administrateurs, équipe SenSaaS avec authentification à deux facteurs, clients	l'équipe accède au domaine client par fédération, pour le support
Un client d'identité par déploiement	chaque plateforme a son identifiant, son adresse de retour et sa déconnexion centralisée	un client unique imposerait des adresses de retour génériques — refusé
Magasin de sessions (Valkey)	les sessions partagées entre les instances du backend	un seul nœud en v0.2, point de panne assumé ; journal d'écriture activé, mot de passe et réseau privé obligatoires
Connecteurs	valider les jetons du serveur d'identité, exposer la liste des dossiers	voir Prérequis d'exploitation
Portail	devient client d'identité et annuaire des connecteurs de l'utilisateur	l'annuaire répond sur le jeton de l'utilisateur, jamais sur un secret de service

Les réglages qui ont une conséquence visible¶

Durée de vie du jeton d'accès : 5 à 15 minutes, renouvelé automatiquement par le backend. Conséquence : si le serveur d'identité tombe, les sessions en cours tiennent au plus ce délai, puis tout le monde doit se reconnecter.
Session de connexion unique : 7 jours (inactivité et durée maximale), sans jeton hors ligne.
Rotation des jetons de renouvellement, avec une seule réutilisation tolérée. C'est ce qui rend indispensable le verrou partagé : plusieurs instances qui renouvelleraient en parallèle détruiraient la session.
Certificat valide sur chaque connecteur. Le backend vérifie le certificat par défaut ; l'accepter sans vérification n'est admis qu'en transition.

Ce que l'exploitant doit surveiller¶

l'état détaillé du backend, qui distingue l'état du magasin de sessions et celui du serveur d'identité ;
la mémoire du magasin de sessions : saturé, il refuse les nouvelles connexions tout en continuant de servir les sessions existantes — un incident qui ne se voit pas dans les journaux d'erreur ;
les journaux du backend, qui portent un identifiant de corrélation par requête, avec les jetons et les cookies masqués.

Provisionner un revendeur¶

Le portail crée le client d'identité du revendeur et l'organisation du client final ; le kit du revendeur reçoit uniquement ses paramètres de connexion. Pas de serveur d'identité dans le kit : un client qui veut rester souverain fédère son propre annuaire depuis le domaine central. Un revendeur compromis n'expose que son propre client.

Ce que le connecteur doit accepter¶

Le connecteur reconnaît deux émetteurs de jetons, distingués par leur origine :

Émetteur	Comment on l'obtient	Usage
le serveur d'identité central	par la connexion depuis l'application	le chemin normal en mode hébergé : connexion unique, comptes gouvernés par SenSaaS
le connecteur lui-même (mode direct)	connexion locale au connecteur, qui émet son propre jeton	réseau local, mode dégradé sans Internet, outils et scripts sur site

Le mode direct est conservé en option, désactivé par défaut sur un connecteur en mode hébergé et activé explicitement quand un site en a besoin. Les deux chemins aboutissent à la même couche d'autorisation : l'adresse électronique de l'utilisateur détermine ses dossiers.

Pour le chemin hébergé, le connecteur n'émet plus rien : il vérifie la signature du jeton avec les clés publiques du serveur d'identité, mises en cache — donc sans appel réseau à chaque requête.

Prérequis¶

Ils sont ordonnés : le backend ne sait parler ni à l'ancienne application ni à un connecteur qui n'accepte pas les jetons centraux. L'ordre exact et le déroulé de la bascule sont sur Bascule v0.1 vers v0.2 ; les éléments d'infrastructure sont détaillés sur Prérequis d'exploitation.

Ce qu'on perd, et qui est assumé¶

C'est une porte à sens unique. Sans base locale ni connexion par mot de passe, revenir au modèle précédent exigerait de reprovisionner les utilisateurs.
Le serveur d'identité devient critique : indisponible, il n'y a plus ni connexion ni renouvellement. Sa haute disponibilité, et celle de sa base, ne sont pas optionnelles.
Le magasin de sessions est le point de panne du kit en version 0.2 : un seul nœud, 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¶

Faut-il migrer des données ?

Non. Les tables d'utilisateurs, de serveurs, de dossiers et de jetons de l'ancien modèle n'ont plus de consommateur. Voir Bascule v0.1 vers v0.2.

Perd-on la possibilité de se connecter sans Internet ?

Non : le mode direct du connecteur est conservé, avec sa connexion locale. Il est désactivé par défaut sur un connecteur en mode hébergé et s'active explicitement.

Que se passe-t-il quand on retire un accès à un utilisateur ?

Le portail peut déclencher sa déconnexion centrale, qui purge sa session sur chaque plateforme. Sans cela, la perte d'accès devient effective au renouvellement suivant du jeton, soit en quelques minutes.