#62 - [EF-10] API REST - brique authentification de l'API - g2/enervision

marvin commented

2026-09-02 08:11:22 +00:00

Member

Exigence couverte

EF-10, ENF-02, ENF-04

Épreuve servie

EC01 — Architecture

Charge estimée

1j

Ce qu'on veut obtenir

Toute la brique d'authentification de l'API : création et gestion des comptes (par un administrateur), connexion par mot de passe, session maintenue en cookies httpOnly, rôles, et le durcissement associé. Les jetons sont émis par l'API - JWT d'accès court, jeton de rafraîchissement opaque à rotation. Seul point d'entrée d'authentification du tableau de bord.

Critères d'acceptation

Comptes:

Un admin crée un compte : POST /auth/users (email, password, role — user par défaut) → 201.
Un admin modifie un compte : PATCH /auth/users/{id} — activer / désactiver, changer le rôle, réinitialiser le mot de passe.
Désactivation ou changement de mot de passe → toutes les sessions de l'utilisateur sont révoquées.
Un admin ne peut pas se retirer ses propres droits ni se désactiver → 409.
Pas d'auto-inscription : un compte est toujours créé par un admin. Le premier admin est posé en SQL (base vide au départ).

Connexion et session:

POST /auth/login (email + mot de passe) → session établie, cookies posés.
Aucun jeton lisible depuis le navigateur : HttpOnly + Secure, ev_refresh restreint au chemin /auth.
Jeton d'accès 15 min ; rafraîchissement 14 j tourné à chaque usage, plafond dur 30 j.
Rejeu d'un jeton de rafraîchissement déjà consommé → session révoquée (détection de vol) ; double appel concurrent toléré dans une fenêtre de grâce.
POST /auth/logout → session révoquée, cookies effacés.
GET /auth/me → profil de l'appelant (id, email, role).

Contrôle d'accès:

Appel sans session → 401 ; jeton invalide ou expiré → 401.
Rôle insuffisant → 403 (rôles user / admin).
Le rôle est vérifié en base à chaque requête, pas seulement d'après le JWT.

Sécurité:

Mots de passe hachés argon2id, jamais stockés ni journalisés en clair.
Login en temps constant (compte connu ou non) — pas d'énumération de comptes.
Limite de débit sur les échecs de connexion, par couple (ip, email).
Journal d'audit de tous les événements — login ok/ko, refresh, rejeu, logout, création et modification de compte (sert EC04).
Contrôle d'origine (CSRF) sur les requêtes mutantes, en plus des cookies SameSite.
Purge des sessions expirées au démarrage.

Comment on le vérifie

tests/unit/ — passwords, tokens, et service (login, rotation, rejeu, logout, update_user) avec un dépôt en mémoire.

Hors périmètre

No response

### Exigence couverte EF-10, ENF-02, ENF-04 ### Épreuve servie EC01 — Architecture ### Charge estimée 1j ### Ce qu'on veut obtenir Toute la brique d'authentification de l'API : création et gestion des comptes (par un administrateur), connexion par mot de passe, session maintenue en cookies httpOnly, rôles, et le durcissement associé. Les jetons sont émis par l'API - JWT d'accès court, jeton de rafraîchissement opaque à rotation. Seul point d'entrée d'authentification du tableau de bord. ### Critères d'acceptation **Comptes:** - [x] Un admin crée un compte : POST /auth/users (email, password, role — user par défaut) → 201. - [x] Un admin modifie un compte : PATCH /auth/users/{id} — activer / désactiver, changer le rôle, réinitialiser le mot de passe. - [x] Désactivation ou changement de mot de passe → toutes les sessions de l'utilisateur sont révoquées. - [x] Un admin ne peut pas se retirer ses propres droits ni se désactiver → 409. - [x] Pas d'auto-inscription : un compte est toujours créé par un admin. Le premier admin est posé en SQL (base vide au départ). **Connexion et session:** - [x] POST /auth/login (email + mot de passe) → session établie, cookies posés. - [x] Aucun jeton lisible depuis le navigateur : HttpOnly + Secure, ev_refresh restreint au chemin /auth. - [x] Jeton d'accès 15 min ; rafraîchissement 14 j tourné à chaque usage, plafond dur 30 j. - [x] Rejeu d'un jeton de rafraîchissement déjà consommé → session révoquée (détection de vol) ; double appel concurrent toléré dans une fenêtre de grâce. - [x] POST /auth/logout → session révoquée, cookies effacés. - [x] GET /auth/me → profil de l'appelant (id, email, role). **Contrôle d'accès:** - [x] Appel sans session → 401 ; jeton invalide ou expiré → 401. - [x] Rôle insuffisant → 403 (rôles user / admin). - [x] Le rôle est vérifié en base à chaque requête, pas seulement d'après le JWT. **Sécurité:** - [x] Mots de passe hachés argon2id, jamais stockés ni journalisés en clair. - [x] Login en temps constant (compte connu ou non) — pas d'énumération de comptes. - [x] Limite de débit sur les échecs de connexion, par couple (ip, email). - [x] Journal d'audit de tous les événements — login ok/ko, refresh, rejeu, logout, création et modification de compte (sert EC04). - [x] Contrôle d'origine (CSRF) sur les requêtes mutantes, en plus des cookies SameSite. - [x] Purge des sessions expirées au démarrage. ### Comment on le vérifie tests/unit/ — passwords, tokens, et service (login, rotation, rejeu, logout, update_user) avec un dépôt en mémoire. ### Hors périmètre _No response_

marvin added the

labels

2026-09-02 08:11:22 +00:00

marvin self-assigned this

2026-09-02 08:11:27 +00:00

marvin changed title from ~~[EF-10]~~ to [EF-10] API REST - brique authentification de l'API

2026-09-02 08:12:18 +00:00