Document de référence présenté dans son intégralité. Le cahier des charges décrit le périmètre prévu ; il ne constitue pas une preuve de recette.
TEC-SEC-009 — Validation stricte des jetons utilisateur
Statut : valide
Priorité : Must
Sources : DEC-0055, DEC-0045
Prescription : Elena doit utiliser Keycloak/OIDC pour le SSO interactif et n’accepter sur ce profil que des JWT utilisateur RS256 dont la signature et les claims de confiance sont validés côté serveur.
Raison fonctionnelle : établir l’identité utilisateur avant d’appliquer l’autorisation, sans confondre identité et droits.
Contraintes et invariants :
RS256 est explicitement autorisé ; none, HS256 et tout autre algorithme sont refusés indépendamment de ce que proposent le jeton ou une clé distante ;
la signature est vérifiée avec les clés JWKS du fournisseur configuré ; le jeton ne choisit pas une source de confiance distante arbitraire ;
sub utilisateur est obligatoire, non vide et valide ; il doit résoudre un acteur utilisateur actif pour construire le contexte authentifié. Email et username ne servent pas d’identité stable ; cet invariant ne refond pas le stockage des identités ;
exp est obligatoire et l’expiration est contrôlée ; nbf, lorsqu’il est présent, doit être valide et ne pas situer le jeton dans le futur hors tolérance configurée ; les valeurs temporelles malformées sont refusées ;
iss correspond exactement à l’émetteur attendu, aud contient l’audience API attendue et azp correspond au client interactif autorisé ; les claims absents, malformés ou discordants sont refusés ;
une configuration de confiance manquante ou invalide (émetteur, audience, client, source JWKS) bloque l’activation du profil et ne désactive jamais un contrôle ; aucune requête n’est authentifiée par défaut.
Données : seules des clés publiques issues du fournisseur autorisé sont mises en cache pour une durée bornée ; les tokens et secrets ne figurent pas dans les preuves ou journaux.
Interfaces et événements : la rotation JWKS et le rafraîchissement sur kid inconnu sont bornés. Une clé connue encore utilisable selon la politique de cache peut vérifier un jeton ; clé inconnue, cache expiré ou signature invérifiable entraînent un refus fermé si le rafraîchissement ne permet pas la validation. Aucun rafraîchissement illimité par requête ou maintien indéfini de clés périmées.
Sécurité et audit : ce profil utilisateur reste distinct des contrats machine-à-machine et clés API, qui ne sont ni interdits ni assimilés à une session interactive. L’identité validée reste soumise à TEC-SEC-006 à 008 ; le JWT n’octroie pas à lui seul un accès métier.
Exploitation : documenter durées de cache, tolérance d’horloge, délais/budgets de rafraîchissement et rotation ; les erreurs de confiance sont visibles sans fuite et sans mode dégradé ou permissif d’authentification en local.
Vérification : VER-SEC-013
Questions ouvertes : aucune
Paramètres et contrats complémentaires à instruire : durées, tolérance d’horloge, stratégie exacte de rotation et contrats machine complémentaires ; aucune valeur numérique supplémentaire n’est actée.
Articulation API : TEC-SEC-010, selon DEC-0137, prescrit les clés API opaques et leur registre serveur ; elles ne passent pas par ce profil JWT.
Réalisation : elena:Modules/Foundation/app/Auth/KeycloakTokenVerifier.php ; conformité à démontrer.