EPIC — Authentification, identité et contrôle d'accès (PD-182)¶

User Stories¶

Intention¶

Mettre en place un système d'authentification et de gestion d'identité robuste, sécurisé et extensible, garantissant que seuls les utilisateurs légitimes accèdent aux ressources qui leur sont strictement autorisées, dans le respect des principes zero-knowledge et des exigences probatoires de ProbatioVault.

Cette EPIC constitue le point d'entrée de confiance de la plateforme.

Problème de fond¶

ProbatioVault manipule des données et preuves à très forte sensibilité. Une authentification faible ou mal conçue entraînerait :

• compromission de comptes et de preuves probatoires ;
• accès non autorisés à des documents chiffrés ou à leurs métadonnées ;
• impossibilité d'attribuer juridiquement une action à un utilisateur ;
• rupture du modèle RLS et de l'isolation des données ;
• non-conformité avec les standards de sécurité modernes (OWASP, RGPD).

Les problématiques clés sont :

• authentifier sans exposer inutilement des secrets ;
• gérer des sessions multiples (multi-device) et leur révocation ;
• appliquer des politiques d'accès fines (RBAC + RLS) ;
• tracer et auditer toutes les authentifications ;
• intégrer des standards éprouvés (JWT, OAuth2/OIDC, MFA).

Solution de principe¶

L'EPIC AUTH met en œuvre une architecture d'authentification hybride et sécurisée, reposant sur les principes suivants :

• Authentification applicative via JWT courts + refresh contrôlés ;
• Gestion des sessions et révocations via Redis ;
• Support MFA avec TOTP conforme RFC 6238 ;
• Intégration OAuth2 / OIDC (Keycloak) pour SSO et B2B ;
• RBAC pour les rôles applicatifs ;
• Activation systématique du RLS PostgreSQL post-authentification ;
• Journalisation exhaustive des événements d'authentification ;
• Support de la révocation device et invalidation immédiate des tokens.

Le système d'authentification devient ainsi un mécanisme de contrôle et de preuve, pas seulement d'accès.

Invariants¶

• Aucune route protégée n'est accessible sans contexte d'identité valide.
• Les tokens sont de durée limitée et révocables.
• Toute authentification (succès ou échec) est auditée.
• Le RLS est activé dès l'établissement de l'identité.
• Les secrets d'authentification ne sont jamais stockés en clair.
• La révocation d'un device invalide immédiatement ses sessions.

User Stories associées¶

• PD-23 — Implémenter inscription utilisateur avec validation
• PD-26 — Configurer OAuth2 / OIDC avec Keycloak
• PD-27 — Implémenter MFA avec TOTP (RFC 6238)
• PD-28 — Créer middleware JWT validation et refresh
• PD-29 — Implémenter RBAC (Role-Based Access Control)
• PD-30 — Configurer session management avec Redis
• PD-31 — Implémenter audit log des authentifications
• PD-32 — Créer endpoints gestion profil utilisateur
• PD-205 — Module Authentication JWT + RLS Activation
• PD-207 — Invalidation tokens lors révocation device

Impacts transverses¶

• Architecture Définition du modèle d'identité et de propagation du contexte utilisateur dans l'ensemble du backend.

• Sécurité Réduction drastique du risque de compromission, MFA, révocation rapide, auditabilité complète.

• UX Équilibre entre sécurité forte et expérience fluide (SSO, refresh transparent, multi-device maîtrisé).

• Mobile / Clients Gestion des tokens, sessions persistantes, révocation device et MFA.

• Juridique Attribution fiable des actions à une identité, traçabilité des connexions et accès aux preuves.

• Exploitation Supervision des tentatives de connexion, détection d'anomalies et réponse aux incidents.

Références¶

• Architecture Executive ProbatioVault — v4.x
• Cahier d'Architecture Technique (Tech Lead)
• Spécifications Authentification & Identité
• Normes : OWASP ASVS, RFC 6238 (TOTP), OAuth2, OIDC, RGPD
• Décisions d'architecture (ADR) liées à l'authentification et au RLS