Authentification, compte et 2FA

Spécification du cœur fonctionnel actuel de telaria : comptes utilisateurs, connexion, vérification d'e-mail, mot de passe oublié, double authentification (2FA) et accès API par token. Reflète l'implémentation existante (tickets CDX-108..115) et le schéma cible de la phase de clean. Statut : spec de référence (doc-design).

1. Objectif et périmètre

telaria est, à ce stade, une application centrée sur le compte utilisateur (le reste — CMS, doc web, IA — vient se greffer dessus). Cette spec documente l'authentification, la gestion de compte, la 2FA et l'accès API.

Dans le périmètre : inscription, vérification d'e-mail, connexion, mot de passe oublié, 2FA, rôles/autorisations, token API, sécurité transverse (CSRF, rate limiting, hardening session). Hors périmètre : CMS (telaria-cms.md), backoffice générique (telaria-admin.md), IA (ia-*.md).

2. Modèle de données (cible)

User

Implémente UserInterface, PasswordAuthenticatedUserInterface, TwoFactorInterface (scheb 2FA e-mail), TrustedDeviceInterface.

ResetPasswordRequest

Entité du bundle SymfonyCasts ResetPassword (jeton, expiration, user).

Deltas de migration (phase clean, VPS-gated)

• Retirer username (+ index UNIQ_IDENTIFIER_USERNAME, accesseurs, usage fixtures) — vestige, la connexion se fait par e-mail.
• api_token : VARCHAR(255) → VARCHAR(128) (l'entité déclare 128 ; la migration Version20251209174030 avait créé 255 → sinon doctrine:schema:validate échoue).
• Ajouter l'index unique sur user.email (aucune contrainte DB ne le garantit aujourd'hui).
• DROP TABLE recipe + category (tables orphelines du démo supprimé).

Workflow : modifier entité + fixtures, puis sur le VPS doctrine:migrations:diff + migration manuelle pour les tables orphelines, puis doctrine:schema:validate.

3. Inscription et vérification d'e-mail

• RegistrationController : formulaire d'inscription (route register), création du compte (isVerified=false).
• EmailVerifier + SymfonyCasts VerifyEmail : envoi d'un lien signé ; routes verify/email (confirmation) et verify/success.
• À la vérification : isVerified=true.

4. Connexion

• SecurityController : connexion par e-mail + mot de passe, CSRF activé, user provider Doctrine sur email.
• Redirection post-login par rôle (v0.5.0) : ROLE_ADMIN → back-office /admin ; ROLE_USER (lecteur) → espace de lecture /lecteur. Cf. §7.
• Session durcie en production (.env.prod.dist, cf. CDX-114).

5. Mot de passe oublié

• ResetPasswordController (SymfonyCasts ResetPassword) : route /password (demande) et /reset/{token} (réinitialisation), jeton à expiration.

6. Double authentification (2FA)

• Actif : scheb/2fa-email (code envoyé par e-mail ; authCode).
• Trusted device : scheb/2fa-trusted-device (trustedVersion) — ne pas redemander la 2FA sur un appareil de confiance.
• TOTP : prévu (totpSecret réservé) ; scheb/2fa-totp à installer le moment venu.
• Pilotage utilisateur : route /2fa/toggle (activation/désactivation, is2faEnabled).

7. Rôles et autorisations

• ROLE_USER (défaut) — lecteur : accès à l'espace de lecture de la veille /lecteur (cf. ia-veille.md ; suivi lu/non-lu par utilisateur, filtres/tri, arborescence des sources). ROLE_ADMIN (backoffice).
• Firewall /admin réservé à ROLE_ADMIN (CDX-109).
• Voters pour la propriété des ressources (CDX-113).
• CSRF sur les actions sensibles (suppressions — CDX-110).

7.1 Comptes lecteur — créés par l'admin (v0.5.0)

• En V1, les comptes lecteur (ROLE_USER) sont créés par l'administrateur via /admin/utilisateurs (UserController) — aujourd'hui création + liste (index + new) ; édition/suppression à venir. Pas d'auto-inscription ouverte pour l'espace lecteur.
• La vitrine publique /veille (billets validés, lecture anonyme) reste conservée et distincte de l'espace lecteur authentifié /lecteur.
• Point ouvert : chantier « gestion des utilisateurs » (auto-inscription + validation) acté au backlog — cf. §13.

8. Accès API (token)

• Authentification par token : APIAuthenticator valide le token en comparant son hash SHA-512 à apiToken (le token en clair n'est jamais stocké).
• Header canonique = X-Auth-Token (exclusif) : l'authenticator ne se déclenche que sur ce header (supports() / authenticate(), vérifié Lead inbox codexia #47, src/Security/APIAuthenticator.php). Bearer n'est pas accepté (un header Bearer ne passe pas supports() → 401). Le schéma Bearer autrefois évoqué dans cette spec est obsolète — pas « les deux ». Un éventuel support Bearer serait une évolution de l'authenticator, pas l'état actuel. Pas-à-pas : tutos/securite-token-api-symfony.md.
• Génération : commande app:user:generate-token (CDX-108) — affiche le token en clair une seule fois, stocke le hash.
• Endpoints : /api, /me (profil courant), /check/email (disponibilité).
• Rate limiting sur l'API (CDX-111).

• Le modèle actuel est un token opaque haché (simple, robuste). OAuth 2.1 / JWT (cf. rfc/README.md, en stand-by) restent une évolution possible, non requise à ce stade.

9. Sécurité transverse

• Rate limiting : connexion, contact, API (symfony/rate-limiter, CDX-111).
• Uploads sécurisés : vérification du type MIME réel + anti path traversal (FileUploader, CDX-112).
• CSRF, hardening session (prod), hachage des mots de passe et des tokens.

10. RGPD et accessibilité

• Données personnelles : e-mail (identifiant). Minimisation : pas de username superflu. Voir la veille RGPD.
• Accessibilité RGAA AA des formulaires (inscription, connexion, reset, 2FA) : labels explicites, erreurs reliées (aria-describedby), focus visible.

11. Tests (cas concrets)

• Unicité e-mail : deux comptes avec le même e-mail → refus (contrainte DB et UniqueEntity).
• Token API : un token valide (hash SHA-512 correspondant) authentifie ; un token inconnu → 401 ; le clair n'est jamais persisté.
• Firewall admin : un ROLE_USER sur /admin → refus (403/redirection).
• Reset : jeton expiré → refus ; jeton valide → changement de mot de passe.
• 2FA : avec is2faEnabled=true, la connexion exige le code e-mail ; un appareil de confiance (trustedVersion courant) ne le redemande pas.
• Rate limiting : dépassement sur login/API/contact → réponse de limitation.
• Vérification e-mail : lien signé valide → isVerified=true ; lien altéré → refus.

12. Production documentaire d'accompagnement (doctrine)

13. Points ouverts

1. TOTP : quand activer scheb/2fa-totp (le champ totpSecret est déjà réservé).
2. Évolution API : rester en token opaque haché, ou passer à OAuth 2.1 / JWT plus tard (RFC en stand-by).
3. Politique de durée de vie / rotation des tokens API.
4. Gestion des utilisateurs lecteur : en V1 les comptes ROLE_USER sont créés par l'admin (cf. §7.1). Chantier ouvert : auto-inscription + validation (workflow d'enrôlement public pour l'espace lecteur).

Documents liés

• Architecture (modèle de données à resynchroniser) : specs/architecture.md
• Backoffice : specs/telaria-admin.md
• Sprint 01 (tickets CDX-108..115) : pilotage/scrum/scrum-sprint-01.md
• API accessible : accessibility/api.md
• Standards OAuth2/JWT (stand-by) : rfc/README.md

Implémentation

Historique des décisions