# ADR-001 : Authentification JWT stockée en localStorage (dérogation à WES ADR-007)

**Statut :** Accepté (dérogation documentée)
**Date :** 2026-07-07
**Contexte :** Authentification de la SPA Vue admin (`resources/js/`)

---

## Contexte

WES ADR-007 prescrit Laravel Sanctum (cookies HttpOnly + CSRF) pour l'authentification web, et rejette explicitement le stockage d'un token en `localStorage` en raison du risque XSS (tout script injecté peut exfiltrer le token).

Un audit WES complet de ce projet (2026-07) a constaté que gestionstock utilise en réalité `php-open-source-saver/jwt-auth`, avec le token stocké côté client dans `window.localStorage` (`resources/js/main/store/auth.js`, `resources/js/common/plugins/axiosAdmin.js`). Ce choix est antérieur à l'adoption de WES par l'équipe : l'application était déjà en production sur cette base avant que WES ADR-007 ne soit rédigé.

Migrer vers Sanctum aujourd'hui impliquerait :
- Réécrire l'intégralité du flux d'authentification (login, refresh, logout) côté backend et frontend.
- Gérer la transition pour tous les utilisateurs déjà connectés (sessions actives, apps mobiles qui pourraient dépendre du même mécanisme JWT).
- Un risque de régression significatif sur un système multi-tenant en production, sans fenêtre de maintenance dédiée planifiée à ce jour.

Ne rien documenter et laisser la contradiction avec l'ADR-007 implicite serait pire : toute décision future qui s'appuierait sur l'ADR-007 pour arbitrer serait fausse dans les faits pour ce projet.

## Décision

Ce projet reste sur JWT + `localStorage` jusqu'à ce qu'une migration vers Sanctum soit explicitement planifiée et budgétée comme un chantier dédié. En attendant, les mitigations suivantes s'appliquent :

- `JWT_TTL` réduit à 480 minutes (8h) au lieu de 10080 (7 jours) — limite la fenêtre d'exploitation d'un token volé.
- Aucune fonctionnalité ne doit être ajoutée qui rendrait la migration future vers Sanctum plus difficile (éviter de coupler davantage de logique métier au mécanisme JWT actuel).
- Toute nouvelle vulnérabilité XSS découverte dans la SPA doit être traitée en priorité Critique, compte tenu de l'exposition directe du token qu'elle implique.

## Alternatives Considérées

### Migration immédiate vers Sanctum
Rejetée : chantier de plusieurs jours à haut risque de régression sur une application multi-tenant déjà en production, sans le disposer d'une fenêtre de maintenance. À planifier séparément si l'équipe le décide.

### Ne rien documenter, laisser la contradiction avec l'ADR-007 implicite
Rejetée : viole la règle WES selon laquelle toute divergence architecturale doit produire un ADR — sans cela, un futur audit ou une future décision continuerait de se tromper sur l'état réel du système.

## Conséquences

- La surface XSS de la SPA admin reste un point d'attention prioritaire (revues de code, CSP à renforcer si possible).
- Un futur ADR de remplacement (statut "Remplacé par ADR-XXX") devra être écrit le jour où la migration vers Sanctum sera effectivement entreprise.

## Quand Réviser

- Si une vulnérabilité XSS est découverte dans la SPA (revoir en urgence).
- Si un chantier de refonte majeure de l'authentification est budgété.
- Si l'application mobile (`abidjanmarche_mobile`) partage un jour ce même backend d'authentification et impose ses propres contraintes.