ADR-002 · JWT pour l'authentification API¶
| Attribut | Valeur |
|---|---|
| Statut | ✅ Accepté |
| Date | Janvier 2024 |
| Décideurs | Équipe technique Primatch |
| Tags | auth, sécurité, api |
Contexte¶
L'API Primatch doit authentifier les requêtes d'une SPA React découplée. Plusieurs approches d'authentification ont été évaluées.
Options évaluées¶
| Option | Avantages | Inconvénients |
|---|---|---|
| Sanctum (cookies/session) | Simple avec Laravel, CSRF managé | Complexe cross-domain, SPA sur port différent |
| JWT (tymon/jwt-auth) | Stateless, facile à gérer côté SPA, standard | Révocation complexe (blacklist nécessaire) |
| Passport (OAuth2) | Standard OAuth2, refresh tokens | Beaucoup de complexité pour une SPA interne |
Décision¶
Nous utilisons JWT (JSON Web Tokens) via le package tymon/jwt-auth avec : - Access token : durée de vie 60 minutes - Refresh token : durée de vie 7 jours - Blacklist activée pour la révocation sur logout
Conséquences¶
✅ Avantages¶
- Authentification stateless, scalable
- Simple à consommer côté React (Bearer token dans headers)
- Compatible avec WebSockets (Soketi)
⚠️ Inconvénients¶
- Les tokens JWT ne peuvent pas être révoqués instantanément sans blacklist
- La blacklist nécessite Redis (mais Redis est déjà dans le stack)
Implementation¶
- Token stocké dans
localStoragecôté frontend pour la persistance entre rechargements de page- Tradeoff : risque XSS théorique, mitigé par la Content Security Policy (CSP), la sanitisation des inputs et l'absence d'injection de contenu tiers
- Intercepteur Axios dans
services/apiClient.tspour auto-refresh - Route de refresh :
POST /api/v1/auth/refresh