Sessions

Une session BlockLucky est un jeton JWT signé par le backend, transmis par le client dans l'en-tête Authorization: Bearer <jeton>. Aucun cookie de session n'est utilisé. La révocation repose sur deux listes tenues dans Redis. Le code est concentré dans backend/src/services/session.service.ts et backend/src/middlewares/auth.middleware.ts.

#Contenu du jeton

Le jeton ne contient ni email ni secret. Il est signé mais pas chiffré : son contenu est lisible par quiconque le détient.

#Signature et vérification

Le test refuse un jeton signé avec un autre algorithme ou sans émetteur de backend/__tests__/api/auth-security.test.ts vérifie ces règles.

#Durée

La durée vient de JWT_EXPIRES_IN, au format <nombre><s|m|h|d>, par défaut 12h. Il n'y a pas de jeton de rafraîchissement : à l'expiration, l'utilisateur se reconnecte avec son mot de passe, son compte Google ou un nouveau code. Ce choix simplifie le modèle (pas de rotation de jetons à gérer) au prix d'une reconnexion deux fois par jour au plus.

#Révocation

flowchart TD
    REQ["Requête avec jeton"] --> DEC["Vérification de signature, iss, aud, exp"]
    DEC -->|"invalide"| E401["401"]
    DEC --> J["auth:revoked:jti présent ?"]
    J -->|"oui"| E401
    J -->|"non"| U["auth:revoked-before:userId postérieur à iat ?"]
    U -->|"oui"| E401
    U -->|"non"| OK["req.user renseigné"]

Deux mécanismes complémentaires :

Les clés Redis sont préfixées par REDIS_KEY_PREFIX et l'environnement (par exemple blocklucky:production:auth:revoked:...). Leur liste complète est sur la page Données Redis.

L'horodatage de révocation globale vaut l'instant de la révocation moins une seconde. Un jeton émis dans la seconde qui précède la révocation peut donc survivre ; c'est ce qui permet au jeton délivré juste après l'activation de la 2FA de rester valide.

#Quand les sessions sont révoquées

La désactivation de la 2FA et le changement d'adresse email (/email/confirm) ne révoquent pas les sessions existantes.

#Déconnexion

POST /api/auth/logout
Authorization: Bearer <jeton>
Content-Type: application/json

{ "allDevices": true }

La réponse contient { "loggedOut": true, "allDevices": true } et l'en-tête Clear-Site-Data: "cache", "cookies", "storage", qui demande au navigateur d'effacer les données du site. Le web appelle cette route depuis useAuth (frontend-web/src/hooks/useAuth.ts) avant de vider son état ; le mobile fait de même dans mobile-app/src/hooks/useAuth.ts. Le bouton « Déconnecter tous mes appareils » du profil web envoie allDevices: true. Le mobile n'a plus de bouton équivalent depuis la refonte des paramètres : signOutEverywhere reste dans useAuth sans être appelé, et un changement de mot de passe est le moyen de déconnecter les autres appareils.

Côté web, une réponse 401 alors qu'un jeton était présent déclenche la déconnexion locale (frontend-web/src/store/api/baseApi.ts). Le mobile n'a pas cette garde : une session révoquée y reste affichée jusqu'à la déconnexion manuelle.

#Droits relus à chaque requête

requireRoles ne fait pas confiance au rôle du jeton. Il relit role, deletedAt et isTwoFactorEnabled en base et répond 403 « Droits révoqués ou modifiés : reconnectez-vous » si le compte a été supprimé ou si son rôle a changé. Le test refuse un jeton dont le rôle ne correspond plus au compte le vérifie. Les routes qui n'utilisent que authenticate (profil, achat de ticket) ne font pas cette relecture : un compte rétrogradé conserve l'accès à ces routes, qui ne demandent de toute façon aucun rôle particulier.

#Stockage du jeton par les clients

Le choix du localStorage évite toute attaque CSRF, puisque le navigateur n'envoie pas le jeton automatiquement. Il expose en revanche le jeton en cas de XSS ; la politique CSP du web, décrite dans Navigateur et mobile, est la principale protection. Un cookie HttpOnly, Secure, SameSite=Strict avec préfixe __Host- serait plus sûr et demanderait d'ajouter une protection CSRF.

#Limites connues