2.3 KiB
2.3 KiB
Authentification & Sécurité (PR-2)
Ce document décrit les mécanismes d'authentification sécurisée mis en place sur le backend Veza.
1. Mécanisme JWT
L'authentification repose sur des tokens JWT (JSON Web Tokens) signés en HS256.
Structure du Token
- Header:
alg:HS256(Strictement vérifié,noneouRS256rejetés)typ:JWT
- Payload (Claims):
sub(Subject): UUID de l'utilisateuriss(Issuer):veza-api(Vérifié strictement)aud(Audience):veza-app(Vérifié strictement)exp(Expiration): Timestamp Unixiat(Issued At): Timestamp Unixtoken_version: Entier (Utilisé pour la révocation)role: Rôle de l'utilisateur (user,admin, etc.)
2. Révocation de Token (TokenVersion)
Pour permettre la révocation immédiate des tokens (stateless) sans blacklist Redis complexe, nous utilisons le concept de TokenVersion.
- Chaque utilisateur possède un champ
token_versionen base de données (entier, défaut 1). - Lors du login, le JWT généré inclut ce
token_versiondans ses claims. - À chaque requête authentifiée, le middleware :
- Valide la signature du JWT.
- Charge l'utilisateur depuis la DB.
- Compare
claim.token_versionavecdb_user.token_version. - Si différent : Rejet immédiat (401 Token revoked).
Cas d'usage:
- Logout "Global" : On incrémente
db_user.token_version. Tous les anciens tokens deviennent invalides instantanément. - Changement de mot de passe : Incrémentation automatique.
- Compte compromis : Incrémentation manuelle par admin.
3. Sécurité Renforcée (P1)
Validation Stricte
Le backend rejette tout token qui ne respecte pas strictement :
alg: Doit êtreHS256.iss: Doit correspondre à la config (JWT_ISSUERou défautveza-api).aud: Doit correspondre à la config (JWT_AUDIENCEou défautveza-app).
Headers requis
Authorization: Bearer <token>
4. Tests et Vérification
Pour vérifier la robustesse de l'auth :
- Tenter de changer l'algo en
none-> 401. - Modifier l'audience -> 401.
- Utiliser un token d'une version n-1 -> 401.
Voir tests/verify_auth.sh pour les tests automatisés.