Cycle de vie d'un utilisateur : invitation, activation, désactivation

Authentification déléguée, autorisation locale

L'app délègue l'authentification à un fournisseur d'identité (ici Logto) : c'est lui qui prouve « tu es bien cette personne » (JWT, MFA, mot de passe). Mais il ne sait rien de ton métier : quel rôle dans quel tenant, quels comptes affectés, qui a été invité mais pas encore connecté.

D'où une règle qui surprend : tu possèdes ton propre annuaire d'autorisation, une table membership locale, distincte du fournisseur.

Le fournisseur d'identité est le videur (il prouve qui tu es) ; ta table membership est la liste des invités (ce que tu as le droit de faire, ton rôle). On ne sous-traite jamais la liste des invités.

Un membership porte : le tenant, l'email (clé d'invitation), le logto_sub (l'identité côté fournisseur, NULL tant que pas activé), le rôle (admin/standard), le statut.

Trois états

invited ──(1re connexion : bind logto_sub)──► active ──(admin désactive)──► deactivated
   │                                                          ▲                    │
   └──(révocation)──► ✗                                       └────(réactive)──────┘

• invited : l'admin a invité par email + rôle. La ligne existe, mais logto_sub est NULL — la personne n'a pas encore d'identité chez nous. C'est pour ça que la colonne est nullable : on invite avant que l'identité existe.
• active : à la 1re connexion réussie, on lie le sub du JWT au membership et on passe active. Ce liage tardif s'appelle le binding JIT (just-in-time).
• deactivated : ne peut plus se connecter, son connecteur personnel est coupé — mais ses données restent (voir plus bas).

Le binding paresseux (JIT) plutôt que le webhook

Deux façons de lier l'identité au membership quand l'invité accepte :

1. Webhook « utilisateur créé » du fournisseur → on lie à la réception.
2. JIT : à la première requête authentifiée, le middleware voit un sub sans membership lié mais avec un email invité correspondant → il lie et active, à la volée.

Le JIT est préférable : aucune dépendance à la livraison d'un webhook (qui peut se perdre, arriver en retard, ou manquer en environnement de test). Le liage se fait sur le chemin qu'on maîtrise — la requête entrante. Principe général : préfère un mécanisme paresseux et auto-réparateur à un mécanisme événementiel fragile, quand l'état peut être reconstruit à la demande.

Désactiver n'est pas supprimer

À la désactivation, on conserve : les affectations de comptes, l'attribution d'audit (created_by), l'historique. On coupe seulement l'accès (connexion) et le routage (connecteur perso). Raisons : traçabilité, et réversibilité (réactiver sans ré-inviter).

Un cas limite à trancher, à connaître : un compte affecté exclusivement à un utilisateur désactivé devient invisible aux standards (plus personne d'actif n'y est affecté) mais reste visible aux admins (is_admin='on'). Faut-il désaffecter automatiquement à la désactivation, ou laisser l'admin réattribuer ? C'est une décision produit, pas technique — mais la mécanique RLS la rend sûre par défaut (jamais de fuite, au pire une invisibilité temporaire côté standard).