@nodefony/security 10.0.0-alpha.7 → 10.0.0-alpha.9

package/docs/audit.md

@@ -30,8 +30,8 @@ source: "src/packages/@nodefony/security/docs/audit.md"
 > Chaque fois qu'une **décision de sécurité** est prise — un login réussit, un accès est refusé, une
 > clé d'API est révoquée, un jeton volé resurgit — Nodefony écrit une ligne dans un journal
 > **append-only** : qui, quoi, quand, d'où, avec quel verdict. Pas le trafic (ça, c'est le log HTTP) :
-> les **transitions d'état**. Ancré sur `AuditService` (`auditService.ts:48`), le contrat
-> `IAuditEvent` (`IAuditEvent.ts:53`) et les stores de `nodefony/src/audit/`.
+> les **transitions d'état**. Ancré sur `AuditService` (`auditService.ts:51`), le contrat
+> `IAuditEvent` (`IAuditEvent.ts:61`) et les stores de `nodefony/src/audit/`.
 
 📍 [Documentation](../../../../../docs/index.md) › [Sécurité](index.md) › **Journal d'audit**
 
@@ -70,7 +70,7 @@ flowchart LR
   API --> UI["Studio — Journal d'audit"]
 ```
 
-`AuditService.record()` (`auditService.ts:180`) est le point de passage unique : il pose l'identité et
+`AuditService.record()` (`auditService.ts:187`) est le point de passage unique : il pose l'identité et
 l'horodatage, écrit **sans attendre**, et notifie les abonnés live. Tout le reste — stores, pont WS,
 webhooks, console — se branche autour de lui.
 
@@ -123,7 +123,7 @@ requête authentifiée qui passe n'écrit rien. Prouvé par les tests « SUCCÈS
 signal, pas du bruit à filtrer.
 
 **2. L'audit ne peut jamais casser le métier.** `record()` est synchrone, sans `await`, et l'écriture
-part en fire-and-forget avec un `.catch()` qui se contente de logger (`auditService.ts:192`). Un
+part en fire-and-forget avec un `.catch()` qui se contente de logger (`auditService.ts:199`). Un
 store en panne dégrade la traçabilité, il ne renvoie pas 500 à l'utilisateur.
 
 **3. Le store est pluggable, jamais câblé en dur.** Le service résout un **nom** via un registre
@@ -196,7 +196,7 @@ export default ExportController;
 ```
 
 > [!IMPORTANT]
-> `category` est une **union fermée** de sous-systèmes de sécurité (`IAuditEvent.ts:16`) : il n'existe
+> `category` est une **union fermée** de sous-systèmes de sécurité (`IAuditEvent.ts:24`) : il n'existe
 > pas de catégorie « métier ». C'est volontaire — ce journal est celui de la sécurité. Range ton
 > événement dans la catégorie de sécurité qu'il concerne (ici `authz` : un accès privilégié à des
 > données) et laisse `action` porter le vocabulaire métier.
@@ -254,7 +254,7 @@ et ratées, sur une fenêtre précise.
 
 Aucune configuration : les événements d'authentification sont émis par défaut. Il suffit de filtrer.
 Les critères se **combinent en ET** et sont traduits par `parseAuditQuery()`
-(`SecurityAdminApi.ts:191`) :
+(`SecurityAdminApi.ts:184`) :
 
 | Paramètre   | Effet                                           | Exemple                     |
 | ----------- | ----------------------------------------------- | --------------------------- |
@@ -312,12 +312,12 @@ use("@nodefony/security", {
 ```
 
 Ce que ça déclenche : le service arme un `GcScheduler` de purge **toutes les heures**
-(`auditService.ts:152`, intervalle `GC_INTERVAL_MS` — `auditService.ts:31`), avec gigue
+(`auditService.ts:159`, intervalle `GC_INTERVAL_MS` — `auditService.ts:34`), avec gigue
 anti-avalanche en cluster. Chaque
 tour appelle la purge du contrat — `gc()`, voisin de `listPage()` dans le même contrat
-(`IAuditStore.ts:67`) — qui supprime les événements plus vieux que la fenêtre : un `DELETE` par seuil
-côté SQL (`DrizzleAuditStore.ts:231`), un défilement de file tant que l'événement de tête dépasse le
-`threshold` côté mémoire (`MemoryAuditStore.ts:127`).
+(`IAuditStore.ts:59`) — qui supprime les événements plus vieux que la fenêtre : un `DELETE` par seuil
+côté SQL (`DrizzleAuditStore.ts:256`), un défilement de file tant que l'événement de tête dépasse le
+`threshold` côté mémoire (`MemoryAuditStore.ts:138`).
 
 Ce qu'on observe dans les logs : `audit gc — 1284 événement(s) purgé(s)` en niveau DEBUG.
 
@@ -331,8 +331,8 @@ qu'il arrive.
 La base est indisponible pendant trente secondes. Que se passe-t-il ?
 
 Le choix de Nodefony est explicite : **le métier passe avant la trace**. L'écriture part en
-fire-and-forget — `append()` sans `await`, échec absorbé en log ERROR (`auditService.ts:192`) ; côté SQL, si l'ORM n'est
-pas connecté, `append()` est un no-op assumé (`DrizzleAuditStore.ts:131`). Un login n'échoue jamais
+fire-and-forget — `append()` sans `await`, échec absorbé en log ERROR (`auditService.ts:199`) ; côté SQL, si l'ORM n'est
+pas connecté, `append()` est un no-op assumé (`DrizzleAuditStore.ts:146`). Un login n'échoue jamais
 parce que le journal est cassé.
 
 > [!WARNING]
@@ -342,22 +342,22 @@ parce que le journal est cassé.
 > disponibilité — le contrat `IAuditStore` (`IAuditStore.ts:48`) est le point d'extension pour ça.
 
 Deux garde-fous limitent la casse au démarrage : un store **explicitement** configuré mais inconnu
-**avorte le boot en production** (`auditService.ts:109`), et un store `memory` en production déclenche
+**avorte le boot en production** (`auditService.ts:115`), et un store `memory` en production déclenche
 un `WARNING` nommant précisément le risque — volatil, per-pod, rétention réglementaire impossible
-(`auditService.ts:122`).
+(`auditService.ts:128`).
 
 ## 🔐 Le catalogue des événements audités
 
-Deux axes de classement. La **catégorie** est une union **fermée** (`IAuditEvent.ts:16`) : c'est
+Deux axes de classement. La **catégorie** est une union **fermée** (`IAuditEvent.ts:24`) : c'est
 l'axe de filtrage principal de la console. L'**action** est une chaîne **ouverte**
-(`IAuditEvent.ts:66`) : la liste grandit sans jamais casser le contrat.
+(`IAuditEvent.ts:74`) : la liste grandit sans jamais casser le contrat.
 
 ### Vue d'ensemble — choisir son filtre en cinq secondes
 
 <!-- prettier-ignore -->
 | Catégorie | Ce qu'elle trace | Actions réellement émises par le framework |
 | --- | --- | --- |
-| `auth` | authentification, chaîne du firewall | `auth.failure` · `auth.throttled` · `auth.denied` · `login.success` · `login.failure` · `login.throttled` · `login.mfa_required` · `user.totp_disabled` |
+| `auth` | authentification, chaîne du firewall | `auth.failure` · `auth.unverifiable` · `auth.throttled` · `auth.denied` · `login.success` · `login.failure` · `login.throttled` · `login.mfa_required` · `user.totp_disabled` |
 | `authz` | autorisation (voters, `@IsGranted`) | `access.denied` |
 | `token` | jetons longue durée et clés d'API | `token.issued` · `token.reuse_detected` · `apikey.created` · `apikey.revoked` |
 | `session` | cycle de vie de session | `logout` |
@@ -369,7 +369,7 @@ l'axe de filtrage principal de la console. L'**action** est une chaîne **ouvert
 | `cors` | politique CORS | _catégorie déclarée, aucune action émise aujourd'hui_ |
 | `config` | mutation de config runtime depuis Studio | _catégorie déclarée, aucune action émise aujourd'hui_ |
 
-Les trois issues possibles (`IAuditEvent.ts:35`) ne sont pas interchangeables : `failure` = **l'acteur
+Les trois issues possibles (`IAuditEvent.ts:43`) ne sont pas interchangeables : `failure` = **l'acteur
 a échoué une preuve** (mauvais mot de passe, signature invalide) ; `denied` = **une politique a
 refusé** un acteur pourtant bien formé (Zero Trust, rôle manquant) ; `success` = l'action a abouti.
 Pour un auditeur, la colonne `denied` est celle des tentatives d'accès non autorisé.
@@ -377,19 +377,21 @@ Pour un auditeur, la colonne `denied` est celle des tentatives d'accès non auto
 ### `auth` — la chaîne d'authentification
 
 Quatre sorties d'échec du firewall passent par le même helper `Firewall.#recordAuth()`
-(`firewall.ts:693`), qui enrichit l'événement de la provenance et pose la **zone** en `resource` :
+(`firewall.ts:900`), qui enrichit l'événement de la provenance et pose la **zone** en `resource` :
 
-- `auth.throttled` — backoff NIST déclenché, réponse 429 (`firewall.ts:768`) ;
-- `auth.failure` — un credential a été **présenté** et rejeté (`firewall.ts:794`) ;
+- `auth.throttled` — backoff NIST déclenché, réponse 429 (`firewall.ts:781`) ;
+- `auth.failure` — un credential a été **présenté** et rejeté (`firewall.ts:807`) ;
+- `auth.unverifiable` — le vérificateur de jetons est indisponible : réponse 503, sans défi
+  (`firewall.ts:795`) ;
 - `auth.denied` / `no_credentials` — Zero Trust : rien n'a été présenté sur une zone protégée
-  (`firewall.ts:811`) ;
+  (`firewall.ts:822`) ;
 - `auth.denied` / `unauthenticated` — un jeton non promu hors `anonymous` (`firewall.ts:850`).
 
 Le parcours de login BFF émet en parallèle son propre vocabulaire depuis `AuthFlow` :
 `login.failure` sur identité inconnue (`authFlow.ts:125`) ou mot de passe faux (`authFlow.ts:153`),
 `login.throttled` (`authFlow.ts:139`), `login.mfa_required` quand un second facteur est réclamé
 (`authFlow.ts:175`), et `login.success` après la preuve complète (`authFlow.ts:191`,
-`authFlow.ts:229`).
+`authFlow.ts:232`).
 
 ### `authz` — le refus d'autorisation
 
@@ -399,10 +401,10 @@ Un seul événement, mais c'est le plus parlant : `access.denied`, émis par le
 ### `token` — la vie et la mort des jetons longue durée
 
 - `token.issued` — un couple access/refresh vient d'être émis, donc une surface d'attaque vient
-  d'être créée ; les `scopes` et l'identifiant du jeton partent en `metadata` (`tokenService.ts:312`) ;
+  d'être créée ; les `scopes` et l'identifiant du jeton partent en `metadata` (`tokenService.ts:535`) ;
 - `token.reuse_detected` — **le signal d'attaque le plus fort du journal** : un refresh déjà révoqué
   a été re-présenté, donc quelqu'un détient un jeton volé. Toute la famille est coupée
-  (`tokenService.ts:353`, RFC 9700 §4.14) ;
+  (`tokenService.ts:585`, RFC 9700 §4.14) ;
 - `apikey.created` / `apikey.revoked` — cycle de vie des clés d'API (`apiKeys.ts:153`,
   `apiKeys.ts:212`).
 
@@ -427,18 +429,18 @@ depuis l'utilisateur de la requête — avec repli `"admin"`, jamais une décisi
 
 ## 🧰 Le contrat d'une entrée
 
-Un événement est un objet **sérialisable JSON** (`IAuditEvent.ts:53`). L'émetteur ne fournit qu'un
-brouillon `IAuditEventDraft` (`IAuditEvent.ts:105`) : `id` et `ts` sont posés par le service, ce qui
+Un événement est un objet **sérialisable JSON** (`IAuditEvent.ts:61`). L'émetteur ne fournit qu'un
+brouillon `IAuditEventDraft` (`IAuditEvent.ts:113`) : `id` et `ts` sont posés par le service, ce qui
 garantit un seul appel d'horloge, centralisé hors des points d'émission.
 
 | Champ       | Type                       | Posé par | Rôle                                                         |
 | ----------- | -------------------------- | -------- | ------------------------------------------------------------ |
 | `id`        | `string`                   | service  | unique dans le process ; sert aussi de composante de curseur |
-| `ts`        | `number` (epoch ms)        | service  | horodatage (`auditService.ts:188`)                           |
+| `ts`        | `number` (epoch ms)        | service  | horodatage (`auditService.ts:195`)                           |
 | `category`  | `AuditCategory`            | émetteur | sous-système — union fermée                                  |
 | `action`    | `string`                   | émetteur | le fait, `<sujet>.<verbe>` — chaîne ouverte                  |
 | `outcome`   | `success\|failure\|denied` | émetteur | le verdict                                                   |
-| `actor`     | `string \| null`           | émetteur | libellé d'identité, `null` si anonyme (`IAuditEvent.ts:74`)  |
+| `actor`     | `string \| null`           | émetteur | libellé d'identité, `null` si anonyme (`IAuditEvent.ts:82`)  |
 | `resource`  | `string \| null`           | émetteur | zone, route, canal, attribut — descripteur **léger**         |
 | `reason`    | `string \| null`           | émetteur | motif **machine** filtrable, pas un message traduit          |
 | `ip`        | `string \| null`           | contexte | provenance réseau                                            |
@@ -458,19 +460,19 @@ Quatre mécanismes, tous prouvés par les tests.
 
 **1. Le chemin nominal n'émet rien.** Ce n'est pas une optimisation, c'est le modèle : le firewall
 n'appelle `#recordAuth()` que depuis ses quatre sorties d'échec, jamais depuis le succès
-(`firewall.ts:900`). Le verrou WS ne tire sa closure `onDeny` que sur refus (`firewall.ts:341`).
-Prouvé : « frame AUTORISÉE → onDeny JAMAIS appelé » (`auditEmissionHotPath.test.ts:324`).
+(`firewall.ts:900`). Le verrou WS ne tire sa closure `onDeny` que sur refus (`firewall.ts:352`).
+Prouvé : « frame AUTORISÉE → onDeny JAMAIS appelé » (`auditEmissionHotPath.test.ts:333`).
 
 **2. Audit désactivé = coût nul, pas juste coût faible.** `record()` sort avant toute allocation et
-avant tout appel d'horloge si le service est inactif (`auditService.ts:182`). Aucun objet créé,
+avant tout appel d'horloge si le service est inactif (`auditService.ts:187`). Aucun objet créé,
 aucun appel d'horloge. Prouvé par le banc « audit désactivé → `issueTokens` n'est pas journalisé »
 (`auditEmissionHotPath.test.ts:499`).
 
 **3. L'écriture ne bloque pas.** `append()` part sans `await`, avec un `.catch()` qui logge
-(`auditService.ts:192`). La latence du store n'entre jamais dans la latence de la requête.
+(`auditService.ts:199`). La latence du store n'entre jamais dans la latence de la requête.
 
 **4. Tout ce qui n'est pas utilisé n'est pas alloué.** La liste d'abonnés live reste `null` tant que
-personne n'écoute et **redevient** `null` au dernier désabonnement (`auditService.ts:221`). Le pont
+personne n'écoute et **redevient** `null` au dernier désabonnement (`auditService.ts:228`). Le pont
 WS n'existe qu'entre le premier et le dernier auditeur connecté, et son tampon circulaire n'est
 alloué qu'au premier événement reçu (`auditBridge.ts:62`) ; son minuteur est armé à la demande et
 `unref` (`auditBridge.ts:93`).
@@ -478,13 +480,13 @@ alloué qu'au premier événement reçu (`auditBridge.ts:62`) ; son minuteur est
 Le pont applique en plus un **coalescing borné** : au plus une frame WS toutes les 250 ms
 (`auditBridge.ts:59`), tampon plafonné à 200 événements (`auditBridge.ts:60`). Sous une rafale
 d'échecs de login, le tampon écrase les plus anciens et compte les omis dans `dropped`
-(`auditBridge.ts:84`) — la console affiche un récapitulatif au lieu de se figer. Superviser ne doit
+(`auditBridge.ts:79`) — la console affiche un récapitulatif au lieu de se figer. Superviser ne doit
 jamais faire tomber ce qu'on supervise.
 
 ## ⚙️ Configuration
 
-Table dérivée du schéma Zod `auditSchema` (`config.ts:877`), rattaché à la racine sous la clé `audit`
-(`config.ts:1152`).
+Table dérivée du schéma Zod `auditSchema` (`config.ts:883`), rattaché à la racine sous la clé `audit`
+(`config.ts:1158`).
 
 | Option          | Type      | Défaut   | Effet                                                                                |
 | --------------- | --------- | -------- | ------------------------------------------------------------------------------------ |
@@ -498,18 +500,18 @@ Table dérivée du schéma Zod `auditSchema` (`config.ts:877`), rattaché à la
 > `immutable` et `stream` sont déclarés dans le schéma mais **ne sont lus par aucun code** aujourd'hui.
 > Les mettre à `false` ne change rien. L'immuabilité vient du **contrat** `IAuditStore`, qui n'expose
 > ni `update` ni `delete` ciblé (`IAuditStore.ts:48`) ; la diffusion live est gouvernée par la
-> **présence d'abonnés** — la liste `#listeners` du service (`auditService.ts:194`).
+> **présence d'abonnés** — la liste `#listeners` du service (`auditService.ts:55`).
 
 ### Comment `store: "auto"` décide
 
 Le défaut ne suppose rien : il **suit l'infrastructure déclarée**, borné aux backends réellement
-enregistrés (`auditService.ts:92`, logique `resolveAutoStore()` dans `infra.ts:289`).
+enregistrés (`auditService.ts:96`, logique `resolveAutoStore()` dans `infra.ts:289`).
 
 1. `NF_STORE` posée et le backend est enregistré pour l'audit → il gagne (levier de banc de charge) ;
 2. sinon, une base est déclarée (`NF_DATABASE_URL`) → `drizzle`, ou `mongoose` selon la famille ;
 3. sinon, repli **annoncé** sur `memory` — la décision est loggée en INFO, jamais silencieuse.
 
-La résolution finale est publiée au kernel (`auditService.ts:139`), ce qui alimente l'écran des stores
+La résolution finale est publiée au kernel (`auditService.ts:145`), ce qui alimente l'écran des stores
 de Studio : configuré, résolu, disponible, motif, emplacement physique.
 
 ## 🏗️ Architecture interne
@@ -536,8 +538,8 @@ Quatre pièces, quatre responsabilités :
 - **`recordAudit()`** (`recordAudit.ts:15`) — le point d'émission côté appelant. Une résolution par le
   container, sur le cold-path uniquement. C'est ce qui rend l'audit **découplé** : module absent →
   aucun effet, jamais d'exception qui remonterait dans le flux métier.
-- **`AuditService`** (`auditService.ts:48`) — le propriétaire. Il construit le store au boot, le pose
-  au container sous le nom `auditStore` (`auditService.ts:138`), arme la purge, et implémente
+- **`AuditService`** (`auditService.ts:51`) — le propriétaire. Il construit le store au boot, le pose
+  au container sous le nom `auditStore` (`auditService.ts:144`), arme la purge, et implémente
   `IAuditSink` (`IAuditStore.ts:77`).
 - **`IAuditStore`** (`IAuditStore.ts:48`) — le contrat de persistance : `append`, `listPage`, `gc`.
   **`append` est la seule écriture** : ni `update`, ni `delete` ciblé. L'immuabilité EST la garantie
@@ -569,27 +571,24 @@ ligne de garde `limit + 1` (`DrizzleAuditStore.ts:198`).
 
 ## Entité de persistance et dialectes pris en charge
 
-**Un seul backend durable** est fourni : `@nodefony/drizzle`. Le décompte honnête :
+**Les deux backends durables portent l'audit** : `@nodefony/drizzle` et `@nodefony/mongoose`. Le
+décompte honnête :
 
-| Backend              | Store d'audit | Dialectes prouvés                   |
+| Backend              | Store d'audit | Moteurs prouvés                     |
 | -------------------- | ------------- | ----------------------------------- |
 | builtin `memory`     | ✅ fourni     | — (mémoire du process, per-pod)     |
 | `@nodefony/drizzle`  | ✅ fourni     | SQLite · PostgreSQL · MySQL/MariaDB |
-| `@nodefony/mongoose` | ❌ absent     | —                                   |
+| `@nodefony/mongoose` | ✅ fourni     | MongoDB                             |
 | `@nodefony/redis`    | ❌ absent     | —                                   |
 
-Mongoose porte session, user, jetons, passkeys et webhooks, mais **pas** l'audit ; Redis non plus.
-Ces deux absences n'ont pas le même statut. Redis n'en aura pas, et la raison n'est pas
-« c'est un cache » — il porte déjà des données durables comme les passkeys, en opt-in assumé. C'est
-que le journal d'audit **croît sans borne**, se conserve des mois pour la conformité, et se
-**consulte** (recherche, filtres, pagination) : garder tout ça en mémoire vive coûte cher pour un
-motif d'accès qui n'est pas le sien. Mongo, lui, est un chemin **durable** :
-l'audit y **manque**, et c'est un manque à combler (objectif « full NoSQL », `MIGRATION_STATUS.md`
-P7.11) — un utilisateur choisit sa base de données, pas de perdre sa traçabilité.
+Une application peut donc tourner **entièrement sur MongoDB** sans perdre sa traçabilité : c'était
+la condition pour que Mongo soit un chemin complet, et pas un chemin qui oblige à rapatrier une
+base SQL pour une seule brique.
 
-En attendant, une application MongoDB qui veut un journal durable a trois voies : brancher un store
-maison (voir l'extension ci-dessous), charger `@nodefony/drizzle` à côté de Mongo — même en SQLite
-local, les deux modules cohabitent — ou héberger le journal sur une base SQL.
+**Redis n'en aura pas, et la raison n'est pas « c'est un cache »** — il porte déjà des données
+durables comme les passkeys, en opt-in assumé. C'est que le journal d'audit **croît sans borne**,
+se conserve des mois pour la conformité, et se **consulte** (recherche, filtres, pagination) :
+garder tout ça en mémoire vive coûte cher pour un motif d'accès qui n'est pas le sien.
 
 ### La table `audit_event`
 
@@ -631,9 +630,9 @@ La règle d'or est écrite en tête du contrat (`IAuditEvent.ts:8`) : **un secre
 Ce que le code garantit, concrètement :
 
 - **Le typage rend le secret difficile à faire entrer.** `actor` est documenté comme un _libellé
-  d'identité_ (`IAuditEvent.ts:74`) et `resource` comme un _descripteur léger_ — « jamais le corps ni
-  les en-têtes de la requête » (`IAuditEvent.ts:79`).
-- **La présence remplace la valeur.** `IAuditEventFlags` (`IAuditEvent.ts:41`) ne porte que deux
+  d'identité_ (`IAuditEvent.ts:82`) et `resource` comme un _descripteur léger_ — « jamais le corps ni
+  les en-têtes de la requête » (`IAuditEvent.ts:87`).
+- **La présence remplace la valeur.** `IAuditEventFlags` (`IAuditEvent.ts:49`) ne porte que deux
   booléens : un en-tête `Authorization` était-il là, un cookie était-il là. `readAuditContext()`
   les calcule par un simple `Boolean(headers[…])` (`readAuditContext.ts:40`) — la valeur n'est jamais
   copiée.
@@ -642,7 +641,7 @@ Ce que le code garantit, concrètement :
   complète de l'événement **ne contient pas** le secret créé
   (`auditEmissionHotPath.test.ts:545`).
 - **Le motif reste machine.** `reason` est une valeur stable et filtrable, pas un message d'erreur
-  libre (`IAuditEvent.ts:84`) : c'est ce qui empêche une cause fine de fuir dans la trace… et qui
+  libre (`IAuditEvent.ts:92`) : c'est ce qui empêche une cause fine de fuir dans la trace… et qui
   permet de la garder **côté audit** alors que le client, lui, reçoit un message d'échec uniforme
   (anti-énumération).
 
@@ -661,11 +660,11 @@ Deux autres propriétés de sécurité valent d'être connues :
 | ----------------------------------------- | --------------------------------- | --------------------------------------------------------------------------------- |
 | Journaliser les échecs d'authentification | OWASP Logging Cheat Sheet         | `auth.failure`/`auth.throttled`/`auth.denied` (`firewall.ts:693`)                 |
 | Journaliser les refus d'autorisation      | OWASP A09:2021                    | `access.denied` sur tout refus du jury (`authorization.ts:130`)                   |
-| Ne jamais journaliser de secret           | OWASP Logging Cheat Sheet         | flags de **présence** seuls (`IAuditEvent.ts:41`)                                 |
-| Traçabilité « qui, quoi, quand, d'où »    | ISO 27001 A.8.15 (journalisation) | acteur, action, horodatage et provenance dans `IAuditEvent` (`IAuditEvent.ts:53`) |
+| Ne jamais journaliser de secret           | OWASP Logging Cheat Sheet         | flags de **présence** seuls (`IAuditEvent.ts:49`)                                 |
+| Traçabilité « qui, quoi, quand, d'où »    | ISO 27001 A.8.15 (journalisation) | acteur, action, horodatage et provenance dans `IAuditEvent` (`IAuditEvent.ts:61`) |
 | Journal inaltérable                       | ISO 27001 A.8.15                  | contrat append-only, aucune mutation exposée (`IAuditStore.ts:48`)                |
-| Rétention bornée / minimisation           | RGPD art. 5.1.e                   | purge par âge pilotée par `retentionDays` (`config.ts:906`)                       |
-| Détection de rejeu de jeton               | RFC 9700 §4.14                    | `token.reuse_detected` + coupure de famille (`tokenService.ts:353`)               |
+| Rétention bornée / minimisation           | RGPD art. 5.1.e                   | purge par âge pilotée par `retentionDays` (`config.ts:912`)                       |
+| Détection de rejeu de jeton               | RFC 9700 §4.14                    | `token.reuse_detected` + coupure de famille (`tokenService.ts:585`)               |
 | Backoff de login journalisé               | NIST SP 800-63B                   | `auth.throttled` avec `reason: "throttled"` (`firewall.ts:773`)                   |
 
 ## 📡 Observabilité — Studio
@@ -675,7 +674,7 @@ L'écran **Sécurité → Journal d'audit** (`/nodefony/audit`) (`Audit.tsx:62`)
 
 - un tableau filtrable par heure, catégorie, action, issue, acteur, raison et IP (`Audit.tsx:227`) ;
 - un indicateur du **store réellement résolu** pour la brique `audit`, alimenté par la publication de
-  résolution du service (`auditService.ts:139`) ;
+  résolution du service (`auditService.ts:145`) ;
 - un interrupteur **Temps réel** qui s'abonne au canal `nodefony:audit` (`AuditLive.tsx:20`) — pensé
   pour les pics d'activité : un journal d'audit se consulte, il ne se regarde pas défiler ;
 - un renvoi vers la **trace de requête** quand l'événement porte un `requestId`, ce qui recolle
@@ -693,19 +692,19 @@ webhook. Détail des souscriptions, de la signature et des relivraisons → [web
 
 ## ⚠️ Pièges
 
-| Symptôme                                            | Cause (dans le code)                                               | Correction                                                 |
-| --------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------- |
-| Journal vide après un redémarrage                   | Store `memory` : volatile et per-pod (`MemoryAuditStore.ts:37`)    | `audit.store: "drizzle"` (ou déclarer `NF_DATABASE_URL`)   |
-| Un pod voit des événements, l'autre non             | Store `memory` non partagé                                         | Store durable partagé                                      |
-| Le boot échoue en production sur l'audit            | Store **explicite** inconnu, fail-closed (`auditService.ts:109`)   | Corriger le nom, ou charger l'adapter qui l'enregistre     |
-| `limit=5000` ne rend que 500 événements             | Plafond du store (`MemoryAuditStore.ts:12`)                        | Paginer avec `nextCursor`, jamais gonfler `limit`          |
-| La page 2 répète ou saute des événements            | Pagination réimplémentée en offset                                 | Repasser le `nextCursor` reçu — le curseur est opaque      |
-| Filtre `?category=authen` sans effet                | Catégorie inconnue **ignorée** (`SecurityAdminApi.ts:191`)         | Utiliser une valeur de l'union (`auth`, `authz`, `token`…) |
-| Le paramètre `q` ne filtre rien                     | Non appliqué sur ce journal (`IAuditStore.ts:20`)                  | Filtrer par `category`/`actor`/`action`/`requestId`        |
-| `stream: false` ne coupe pas le live                | Drapeau non lu ; le live suit `#listeners` (`auditService.ts:194`) | Retirer le rôle admin, ou ne pas exposer le canal          |
-| Trous dans le journal pendant une panne de base     | Écriture best-effort (`auditService.ts:192`)                       | Store à haute disponibilité si la conformité l'exige       |
-| Aucun `login.success` alors que les logins marchent | Le succès du **firewall** est muet ; `login.success` vient du BFF  | Filtrer `action=login.success`, pas `category=auth` seul   |
-| Endpoint d'audit en 503                             | `audit.enabled: false` (`SecurityAdminApi.ts:320`)                 | Réactiver l'audit en configuration                         |
+| Symptôme                                            | Cause (dans le code)                                              | Correction                                                 |
+| --------------------------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------- |
+| Journal vide après un redémarrage                   | Store `memory` : volatile et per-pod (`MemoryAuditStore.ts:37`)   | `audit.store: "drizzle"` (ou déclarer `NF_DATABASE_URL`)   |
+| Un pod voit des événements, l'autre non             | Store `memory` non partagé                                        | Store durable partagé                                      |
+| Le boot échoue en production sur l'audit            | Store **explicite** inconnu, fail-closed (`auditService.ts:115`)  | Corriger le nom, ou charger l'adapter qui l'enregistre     |
+| `limit=5000` ne rend que 500 événements             | Plafond du store (`MemoryAuditStore.ts:12`)                       | Paginer avec `nextCursor`, jamais gonfler `limit`          |
+| La page 2 répète ou saute des événements            | Pagination réimplémentée en offset                                | Repasser le `nextCursor` reçu — le curseur est opaque      |
+| Filtre `?category=authen` sans effet                | Catégorie inconnue **ignorée** (`SecurityAdminApi.ts:191`)        | Utiliser une valeur de l'union (`auth`, `authz`, `token`…) |
+| Le paramètre `q` ne filtre rien                     | Non appliqué sur ce journal (`IAuditStore.ts:20`)                 | Filtrer par `category`/`actor`/`action`/`requestId`        |
+| `stream: false` ne coupe pas le live                | Drapeau non lu ; le live suit `#listeners` (`auditService.ts:55`) | Retirer le rôle admin, ou ne pas exposer le canal          |
+| Trous dans le journal pendant une panne de base     | Écriture best-effort (`auditService.ts:199`)                      | Store à haute disponibilité si la conformité l'exige       |
+| Aucun `login.success` alors que les logins marchent | Le succès du **firewall** est muet ; `login.success` vient du BFF | Filtrer `action=login.success`, pas `category=auth` seul   |
+| Endpoint d'audit en 503                             | `audit.enabled: false` (`SecurityAdminApi.ts:320`)                | Réactiver l'audit en configuration                         |
 
 ## 🧪 Tests & couverture
 

package/docs/authenticators.md

@@ -31,7 +31,7 @@ source: "src/packages/@nodefony/security/docs/authenticators.md"
 > Un **authenticator** répond à une seule question : _« qui es-tu, et peux-tu le prouver ? »_. Il ne
 > décide **pas** des droits (ça, c'est l'autorisation / les voters) — il établit une **identité**.
 > Le firewall enchaîne les authenticators déclarés par une zone jusqu'à obtenir une preuve valide,
-> sinon il ferme en 401 (Zero Trust). Nodefony en fournit **six** intégrés, tous ancrés ici sur le
+> sinon il ferme en 401 (Zero Trust). Nodefony en fournit **sept** intégrés, tous ancrés ici sur le
 > code (`src/packages/@nodefony/security/nodefony/src/authenticator/`).
 
 📍 [Documentation](../../../../../docs/index.md) › [Sécurité](index.md) › **Authenticators**
@@ -90,7 +90,7 @@ classe d'attaque précise — détaillées brique par brique dans le catalogue :
 
 ### Le contrat `IAuthenticator`
 
-Tout authenticator implémente le même cycle (`IAuthenticator.ts:18`), ce qui rend le firewall
+Tout authenticator implémente le même cycle (`IAuthenticator.ts:23`), ce qui rend le firewall
 totalement agnostique de la stratégie :
 
 | Méthode               | Rôle                                                                                                       |
@@ -100,7 +100,7 @@ totalement agnostique de la stratégie :
 | `authenticate(token)` | **Vérifie** (signature/hash/session), applique la **révocation**, **re-résout le sujet** — ou lève un 401. |
 | `onSuccess(ctx,tok)`  | Effet de bord au succès (poser l'identité en session, audit).                                              |
 | `onFailure(ctx,err)`  | Slot d'audit (le 401 + challenge sont posés par le firewall).                                              |
-| `challenge()`         | **Optionnel** (`IAuthenticator.ts:42`) — la valeur `WWW-Authenticate` (RFC 7235) des 401 de la zone.       |
+| `challenge()`         | **Optionnel** (`IAuthenticator.ts:55`) — la valeur `WWW-Authenticate` (RFC 7235) des 401 de la zone.       |
 
 ### Le registre pluggable
 
@@ -108,11 +108,11 @@ Les authenticators sont résolus par **nom** : `Firewall.#instantiateAuthenticat
 (`firewall.ts:429`) interroge `getAuthenticatorFactory()` (`authenticatorRegistry.ts:59`) — jamais
 un `if (name === "jwt")` dans le firewall, qui trahirait la promesse « pluggable ».
 
-- Les **cinq builtins HTTP** (`anonymous`, `userpassword`, `session`, `jwt`, `apikey`)
+- Les **six builtins HTTP** (`anonymous`, `userpassword`, `session`, `jwt`, `external-jwt`, `apikey`)
   s'enregistrent à l'import du module via `registerAuthenticatorFactory()`
-  (`authenticatorRegistry.ts:72-125`) — donc toujours avant le boot.
-- Le sixième, `firewall-realtime`, n'est **pas dans le registre** : c'est le firewall qui le câble
-  lui-même au handshake WS des zones protégées (`Firewall.#wireRealtime()`, `firewall.ts:268`).
+  (`authenticatorRegistry.ts:73-145`) — donc toujours avant le boot.
+- Le septième, `firewall-realtime`, n'est **pas dans le registre** : c'est le firewall qui le câble
+  lui-même au handshake WS des zones protégées (`Firewall.#wireRealtime()`, `firewall.ts:279`).
 - La fabrique ne fait que **construire** ; les résolutions de services coûteuses (`users`,
   `tokenStore`, keystore) restent **lazy** dans l'instance (cold path).
 - Un nom inconnu en config = boot **fail-closed** — `#configError` posé + log CRITIC
@@ -205,16 +205,17 @@ Requête par requête, qui répond :
 | `Authorization: Bearer nf_…`         | `apikey`               | identifié — clé vérifiée au store, révocable              |
 | rien                                 | aucun                  | **401** + `WWW-Authenticate: Bearer` (`firewall.ts:1200`) |
 
-## 🔐 Les six authenticators intégrés
+## 🔐 Les authenticators intégrés
 
-| Nom                 | Credential                               | Vérité     | Révocable | Pour…                              |
-| ------------------- | ---------------------------------------- | ---------- | :-------: | ---------------------------------- |
-| `anonymous`         | (aucun)                                  | —          |     —     | accepter l'anonymat explicitement  |
-| `userpassword`      | `Authorization: Basic base64(id:mdp)`    | verifier   |    n/a    | outils/scripts, brique login       |
-| `session`           | cookie de session (identifiant en blob)  | serveur    | immédiate | le **web** après login (BFF)       |
-| `jwt`               | `Authorization: Bearer <a.b.c>`          | auto-porté | via état  | API service↔service, agents        |
-| `apikey`            | `Authorization: Bearer nf_…`             | serveur    | immédiate | API/CI/scripts d'un user           |
-| `firewall-realtime` | identité déjà résolue au handshake (ALS) | serveur    | 1 fenêtre | le **WebSocket** de toute identité |
+| Nom                 | Credential                                          | Vérité     |   Révocable    | Pour…                                      |
+| ------------------- | --------------------------------------------------- | ---------- | :------------: | ------------------------------------------ |
+| `anonymous`         | (aucun)                                             | —          |       —        | accepter l'anonymat explicitement          |
+| `userpassword`      | `Authorization: Basic base64(id:mdp)`               | verifier   |      n/a       | outils/scripts, brique login               |
+| `session`           | cookie de session (identifiant en blob)             | serveur    |   immédiate    | le **web** après login (BFF)               |
+| `jwt`               | `Authorization: Bearer <a.b.c>`                     | auto-porté |    via état    | API service↔service, agents                |
+| `external-jwt`      | `Authorization: Bearer <a.b.c>` d'un émetteur TIERS | émetteur   | via l'émetteur | jetons d'un serveur d'autorisation externe |
+| `apikey`            | `Authorization: Bearer nf_…`                        | serveur    |   immédiate    | API/CI/scripts d'un user                   |
+| `firewall-realtime` | identité déjà résolue au handshake (ALS)            | serveur    |   1 fenêtre    | le **WebSocket** de toute identité         |
 
 ### `anonymous` — accepter explicitement l'anonymat
 
@@ -235,7 +236,7 @@ Le seul authenticator autorisé à produire un token **non authentifié** sans d
 
 Schéma **HTTP Basic** (RFC 7617) : `Authorization: Basic base64(id:mdp)`, charset UTF-8, scheme
 case-insensitive (`UserPasswordAuthenticator.ts:11`) ; `createToken()` split au **premier** `:` —
-le mot de passe peut en contenir (`UserPasswordAuthenticator.ts:74`).
+le mot de passe peut en contenir (`UserPasswordAuthenticator.ts:68`).
 
 - **La vérification est déléguée** au `IPasswordVerifier` (le `UserService`) : hash, comparaison,
   leurre anti-timing, re-hash transparent — l'authenticator ne voit que le verdict.
@@ -245,7 +246,7 @@ le mot de passe peut en contenir (`UserPasswordAuthenticator.ts:74`).
   (`UserPasswordAuthenticator.ts:101-103`) — un identifiant bloqué ne coûte **aucun hash** → le
   throttle protège aussi le serveur du **DoS argon2**. Échec compté, succès remis à zéro
   (`UserPasswordAuthenticator.ts:111-114`). `ThrottledError` → **429 + `Retry-After`**
-  (`firewall.ts:764`).
+  (`firewall.ts:780`).
 - **Le throttler est PARTAGÉ** avec le login JSON du BFF — même `loginThrottler` du container : un
   attaquant ne contourne pas le backoff en changeant de porte (`authenticatorRegistry.ts:75-79`).
 - Challenge : `Basic realm="nodefony", charset="UTF-8"` (`UserPasswordAuthenticator.ts:130`).
@@ -258,7 +259,7 @@ Après le login, chaque requête web prouve son identité par la **session serve
 Credential = l'**identifiant** posé dans le blob de session, jamais un secret.
 
 - **N'ouvre jamais la session lui-même** : `supports()` exige une session **déjà reprise** porteuse
-  d'un utilisateur (`SessionAuthenticator.ts:43-46`) — le pipeline http démarre la session _avant_
+  d'un utilisateur (`SessionAuthenticator.ts:75-78`) — le pipeline http démarre la session _avant_
   le firewall ; c'est `AuthFlow.login()` qui ouvre et régénère l'ID (anti-fixation).
 - **L'identité est re-résolue à CHAQUE requête** via `resolveSessionIdentity`
   (`SessionAuthenticator.ts:91`) → rôles frais, révocation immédiate. Les contrôles d'état sont
@@ -272,21 +273,32 @@ Credential = l'**identifiant** posé dans le blob de session, jamais un secret.
 
 Réservé aux **API service↔service / agents** (le web reste sur la session). Vérifie un access token
 **EdDSA** signé par le keystore du serveur ; `supports()` ne réclame que la structure compacte
-`a.b.c` (`COMPACT_JWS`, `JwtAuthenticator.ts:20`). Les défenses **dures** du JWT BCP, toutes
+`a.b.c` (`COMPACT_JWS`, `JwtAuthenticator.ts:21`). Les défenses **dures** du JWT BCP, toutes
 prouvées en test :
 
 | Défense                                | Comment                                                                                          | Attaque fermée                                                     |
 | -------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------ |
 | **Allowlist d'algorithmes**            | `algorithms: ["EdDSA"]` — jamais l'algo de l'en-tête du token (`JwtAuthenticator.ts:120`)        | `alg=none`, algorithm confusion (§3.1)                             |
-| **Clé par `kid` du keyset LOCAL**      | `createLocalJWKSet` — jamais `jku`/`jwk` de l'en-tête (`JwtAuthenticator.ts:158`)                | injection de clé / SSRF (§3.5)                                     |
-| **`aud` + `iss` + `typ` obligatoires** | `typ: "at+jwt"` (§3.11) sépare access et refresh (`JwtAuthenticator.ts:105-107`)                 | refresh présenté comme access, token d'un autre service (§3.8-3.9) |
-| **Révocation**                         | denylist `isJtiDenied` + seuil `invalidBefore` par porteur (`JwtAuthenticator.ts:123-131`)       | jeton auto-porté volé, logout global                               |
-| **Sujet revérifié**                    | `loadUserByIdentifier(sub)` → disparu/inactif/verrouillé = rejet (`JwtAuthenticator.ts:174-186`) | compte banni encore « valide » via son token (§3.10)               |
+| **Clé par `kid` du keyset LOCAL**      | `createLocalJWKSet` — jamais `jku`/`jwk` de l'en-tête (`JwtAuthenticator.ts:174`)                | injection de clé / SSRF (§3.5)                                     |
+| **`aud` + `iss` + `typ` obligatoires** | `typ: "at+jwt"` (§3.11) sépare access et refresh (`JwtAuthenticator.ts:119-124`)                 | refresh présenté comme access, token d'un autre service (§3.8-3.9) |
+| **Révocation**                         | denylist `isJtiDenied` + seuil `invalidBefore` par porteur (`JwtAuthenticator.ts:138-148`)       | jeton auto-porté volé, logout global                               |
+| **Sujet revérifié**                    | `loadUserByIdentifier(sub)` → disparu/inactif/verrouillé = rejet (`JwtAuthenticator.ts:190-203`) | compte banni encore « valide » via son token (§3.10)               |
 
-Le **message d'échec est uniforme** (`INVALID_TOKEN`, `JwtAuthenticator.ts:24`) : la cause fine
+Le **message d'échec est uniforme** (`INVALID_TOKEN`, `JwtAuthenticator.ts:25`) : la cause fine
 (expiré, `aud`, signature, sujet banni) part en **audit**, jamais au client — anti-oracle. Le token
-promu porte `scopes`, `jti`, `claims` en attributs (`JwtAuthenticator.ts:162-171`). `jose` est
-importé **lazy** — dépendance lourde (`JwtAuthenticator.ts:96`).
+promu porte `scopes`, `jti`, `claims` en attributs (`JwtAuthenticator.ts:178-188`). `jose` est
+importé **lazy** — dépendance lourde (`JwtAuthenticator.ts:112`).
+
+Les six premiers se déclarent dans une zone (registre `authenticatorRegistry.ts:73`) ;
+`firewall-realtime` ne se déclare pas — le firewall le câble lui-même au handshake WebSocket.
+
+### `external-jwt` — un jeton émis par un serveur d'autorisation TIERS
+
+Là où `jwt` ne vérifie que les jetons signés par Nodefony, `external-jwt` accepte un jeton d'un
+émetteur de confiance déclaré (`resourceServer.issuers`), vérifié contre ses clés publiques, et
+rattache son sujet à un compte local. `jwt` et `external-jwt` s'aiguillent par l'émetteur (`iss`) :
+leur ordre dans la zone ne décide de rien. Tout le détail — audience, espace de noms du sujet, panne
+de l'émetteur en 503 — est dans **[Jetons d'un émetteur tiers](external-jwt.md)**.
 
 ### `apikey` — PAT opaque révocable
 
@@ -294,17 +306,17 @@ Clé API personnelle en `Authorization: Bearer nf_…` (préfixe `apiKeys.prefix
 Contrairement au JWT (auto-porté), un PAT est un **bearer opaque** dont la vérité vit **côté
 serveur** (`ITokenStore`) → **révocable immédiatement**. Défenses :
 
-- **Forme + CRC validés AVANT tout accès au store** (`parseApiKey`, `ApiKeyAuthenticator.ts:99-101`)
+- **Forme + CRC validés AVANT tout accès au store** (`parseApiKey`, `ApiKeyAuthenticator.ts:103-106`)
   → une valeur malformée n'atteint jamais la base (**anti-DoS**).
-- **Lookup par hash SHA-256** (`findByHash`, `ApiKeyAuthenticator.ts:105`) — le secret n'existe
+- **Lookup par hash SHA-256** (`findByHash`, `ApiKeyAuthenticator.ts:109`) — le secret n'existe
   **nulle part au repos**.
-- **Révocation** (`revokedAt`) + **expiration** (`expiresAt`) (`ApiKeyAuthenticator.ts:109-111`) +
-  **ban en masse** du porteur (`invalidBefore` vs `createdAt`, `ApiKeyAuthenticator.ts:117-118`).
-- **Sujet revérifié** à chaque requête → rôles frais (`ApiKeyAuthenticator.ts:123`).
+- **Révocation** (`revokedAt`) + **expiration** (`expiresAt`) (`ApiKeyAuthenticator.ts:113-116`) +
+  **ban en masse** du porteur (`invalidBefore` vs `createdAt`, `ApiKeyAuthenticator.ts:121-122`).
+- **Sujet revérifié** à chaque requête → rôles frais (`ApiKeyAuthenticator.ts:127`).
 - **`lastUsedAt` throttlé** : aucune écriture sur le hot path tant que la fenêtre
-  `apiKeys.lastUsedThrottleS` n'est pas dépassée (`ApiKeyAuthenticator.ts:127-133`).
+  `apiKeys.lastUsedThrottleS` n'est pas dépassée (`ApiKeyAuthenticator.ts:136-143`).
 
-Le token promu porte `scopes`, `apiKeyId`, `tenantId` (`ApiKeyAuthenticator.ts:138-140`).
+Le token promu porte `scopes`, `apiKeyId`, `tenantId` (`ApiKeyAuthenticator.ts:146-149`).
 
 ### `firewall-realtime` — la promotion, en WebSocket, de l'identité déjà posée
 
@@ -323,7 +335,7 @@ l'ALS. `FirewallRealtimeAuthenticator.supports()` ne fait que le constater
 - **Perf : il ne relit pas la base.** `authenticate()` réutilise l'identité de l'ALS
   (`FirewallRealtimeAuthenticator.ts:91`) au lieu de refaire deux lectures base par connexion —
   un coût évitable sur le différenciateur temps réel.
-- **Câblé automatiquement** par `Firewall.#wireRealtime()` (`firewall.ts:268`) pour toute zone
+- **Câblé automatiquement** par `Firewall.#wireRealtime()` (`firewall.ts:279`) pour toute zone
   protégée `realtime !== false` — une instance par zone au handshake (`firewall.ts:289`).
 - **Le mode de preuve suit le jeton du firewall**, il n'est pas deviné : absent (zone historique),
   on retombe sur le mode le plus strict, la session (`FirewallRealtimeAuthenticator.ts:101-103`).
@@ -333,7 +345,7 @@ l'ALS. `FirewallRealtimeAuthenticator.supports()` ne fait que le constater
   `buildSessionRevalidator()` re-lit `storage.read(id)` et compare l'identifiant ; toute erreur de
   lecture invalide, fail-closed (`FirewallRealtimeAuthenticator.ts:227`). En mode jeton porteur, la
   preuve est autre : `exp`, `jti` denylisté, `invalidBefore`
-  (`FirewallRealtimeAuthenticator.ts:127`).
+  (`FirewallRealtimeAuthenticator.ts:179`).
 
 > [!NOTE]
 > **Asymétrie de révocation HTTP↔WS (assumée)** : le jeton realtime est figé au handshake (les
@@ -344,7 +356,7 @@ l'ALS. `FirewallRealtimeAuthenticator.supports()` ne fait que le constater
 ## ⚙️ Composer une zone — ordre, mode, cohabitation
 
 La liste `area.authenticators` se lit **dans l'ordre**, déroulée par `Firewall.#authenticate()`
-(`firewall.ts:1112`) selon le `mode` de la zone (`first` par défaut, `config.ts:87-92`).
+(`firewall.ts:1128`) selon le `mode` de la zone (`first` par défaut, `config.ts:87-92`).
 
 ### Situation 1 — humains ET machines sur la même API (`first`)
 
@@ -377,14 +389,14 @@ authenticators: ["anonymous", "session"],   // ❌ anonymous accepte TOUT le mon
 ### Situation 3 — empiler les preuves (`all`)
 
 En mode `all`, **chaque** maillon est obligatoire : `supports()` faux = 401 immédiat
-(`firewall.ts:937`) et le **dernier** token de la chaîne porte l'identité (`firewall.ts:973`) —
+(`firewall.ts:1144-1149`) et le **dernier** token de la chaîne porte l'identité (`firewall.ts:1198-1199`) —
 utile pour exiger une preuve de canal (mTLS) **et** une identité, ou un « sudo mode » session +
 re-saisie du mot de passe. Scénario complet côté zones : [firewall](./firewall.md).
 
 ### Cohabitation JWT + clé API dans une même zone
 
 Les deux sont des `Bearer`, mais Nodefony les **discrimine sur la forme** — un JWT a la structure
-compacte `a.b.c` (`COMPACT_JWS`, `JwtAuthenticator.ts:20`), un PAT porte le préfixe `nf_` sans
+compacte `a.b.c` (`COMPACT_JWS`, `JwtAuthenticator.ts:21`), un PAT porte le préfixe `nf_` sans
 point (`looksLikeApiKey`, `ApiKeyAuthenticator.ts:72`). Chaque `supports()` ne réclame que _son_
 format → aucun conflit, aucune double vérification.
 
@@ -428,8 +440,8 @@ registerAuthenticatorFactory("ldap", ({ container, config }) => {
 | JWT (BCP) | RFC 7519, 8725 | `jwtVerify` durci : allowlist + claims (`JwtAuthenticator.ts:103-107`) |
 | HTTP Basic | RFC 7617 | `UserPasswordAuthenticator` (`UserPasswordAuthenticator.ts:25-27`) |
 | Backoff de login | NIST SP 800-63B | `#throttler.check()` avant le verifier (`UserPasswordAuthenticator.ts:101-103`) |
-| Rate limit (429) | RFC 6585 | `Retry-After` posé par le firewall (`firewall.ts:764`) |
-| Anti-énumération | OWASP | `INVALID_TOKEN` (`JwtAuthenticator.ts:24`) · `INVALID_CREDENTIALS` (`UserPasswordAuthenticator.ts:16`) |
+| Rate limit (429) | RFC 6585 | `Retry-After` posé par le firewall (`firewall.ts:780`) |
+| Anti-énumération | OWASP | `INVALID_TOKEN` (`JwtAuthenticator.ts:25`) · `INVALID_CREDENTIALS` (`UserPasswordAuthenticator.ts:16`) |
 
 ## ⚡ Performance & mémoire
 
@@ -437,7 +449,7 @@ registerAuthenticatorFactory("ldap", ({ container, config }) => {
   (le chemin chaud/froid vit dans le [firewall](./firewall.md)).
 - Résolutions **lazy** : le verifier `#resolveVerifier` est mémoïsé au premier login
   (`UserPasswordAuthenticator.ts:105`) ; keystore, `tokenStore` et `users` sont résolus du
-  container au premier usage ; `jose` est importé lazy (`JwtAuthenticator.ts:96`).
+  container au premier usage ; `jose` est importé lazy (`JwtAuthenticator.ts:112`).
 - `anonymous` : singleton gelé `anonymousUser`, zéro allocation d'utilisateur
   (`AnonymousToken.ts:9`).
 - `apikey` : écriture `lastUsedAt` **coalescée** — pas une écriture par requête
@@ -456,7 +468,7 @@ registerAuthenticatorFactory("ldap", ({ container, config }) => {
 | JWT rejeté alors qu'il « semble » valide | `aud`/`iss`/`typ` non conformes, ou `alg` ≠ EdDSA (`JwtAuthenticator.ts:103-107`) | Émettre via le `TokenService` (mêmes iss/aud/typ) |
 | Clé API révoquée encore acceptée quelques secondes | Confusion avec un JWT (auto-porté) — `revokedAt` est lu à chaque requête (`ApiKeyAuthenticator.ts:110`) | Un PAT est révoqué immédiatement ; vérifier `revokedAt` |
 | Révocation WS pas immédiate | Identité figée au handshake — asymétrie assumée du `FirewallRealtimeAuthenticator` (`FirewallRealtimeAuthenticator.ts:51-55`) | Attendre la fenêtre de re-validation, ou utiliser JWT + canal révocation |
-| Brute-force pas ralenti | `loginThrottler` absent du container — `rateLimit.enabled` off (`firewall.ts:617`) | Configurer `rateLimit` pour poser le throttler |
+| Brute-force pas ralenti | `loginThrottler` absent du container — `rateLimit.enabled` off (`firewall.ts:613`) | Configurer `rateLimit` pour poser le throttler |
 
 ## 🧪 Tests & couverture