JWT, JWKS et la résolution du tenant

Valider un JWT, la version sérieuse

Le middleware d'auth valide chaque Bearer token émis par Logto. Les détails qui séparent une validation correcte d'une faille :

1. Whitelist d'algos asymétriques uniquement (RS/ES/PS 256-512, Logto signe en ES384). Le HS* est explicitement exclu — c'est la parade à l'attaque alg confusion : un attaquant forge un token alg: HS256 signé avec… la clé publique comme secret HMAC. Si le code accepte les deux familles, la clé publique (publique !) devient une clé de signature valide ;
2. l'algo lu dans le header doit appartenir à la whitelist, et SEUL cet algo est passé au décodeur — jamais une liste large ;
3. signature + iss + aud + exp vérifiés — avec la subtilité multi-audiences (Logto stampe l'aud différemment selon le type de token → on boucle sur les audiences acceptées).

Le cache JWKS : chaud, mais prêt pour la rotation

Les clés publiques de Logto viennent du endpoint JWKS. Les récupérer à chaque requête serait un aller-réseau sur le hot path ; les cacher trop fort casserait la rotation de clés. Le pattern :

cache in-memory, TTL 1 h
kid connu   → validation sans aucune I/O
kid INCONNU → UN refresh forcé du JWKS, puis re-recherche
              (une clé vient de tourner — ou le token est forgé, et échouera)

Ce « refresh-on-miss » est réutilisable pour tout secret distant qui tourne : chaud par défaut, correct pendant les rotations, et un token forgé ne coûte qu'un fetch.

Du token au tenant : la chaîne complète

Bearer ES384 → validation → organizations du token
  → header X-Org-Id ∈ organizations ?  (l'utilisateur EST membre de l'org qu'il prétend)
  → SQL : tenant_identity_for_logto_org(org) → tenant_id local
  → request.state.{user_id, tenant_id, principal} + contexte de logs bindé

C'est CE tenant_id qui alimente la session RLS du module 3 — l'isolation part du token. Le provisioning ferme la boucle : à l'inscription, un endpoint dédié (JWT requis mais sans check tenant — c'est lui qui le crée) synchronise l'organisation Logto vers un tenant local ; un script CLI idempotent pilote l'API Management de Logto pour créer apps et resources.