ADR 0002 : Authentification via Supabase Auth natif (abandon de la couche « maison »)
- Statut : Accepté
- Décideurs : Marco (Commanditaire), Julien (Commanditaire), Seer (Développeur)
- Date : 8 juillet 2026
Contexte et Problème
L'ADR 0001 a acté la migration vers Supabase. Lors de la première mise en œuvre, une dérive d'architecture s'est installée, hors du plan validé (voir docs/features/handoff_migration_supabase.md) :
- Codes PIN hachés « maison » : colonnes
pin_hashet appels àcrypt()gérés manuellement. - « Jetons » de connexion (JWT) fabriqués à la main, signés côté application.
- Rôles incohérents (
admin/employee) ne correspondant pas au brief. - Un membre = un seul projet, alors que le métier exige le multi-projets.
Ce modèle est à la fois moins sûr (un JWT forgé maison peut ouvrir un accès, la vérification des PIN est faite hors du système d'auth) et plus coûteux à maintenir (réimplémentation de briques déjà fournies par Supabase).
Facteurs de Décision
- Sécurité : le hachage et la vérification des mots de passe doivent reposer sur une brique éprouvée, pas sur du code applicatif.
- Conformité au brief : rôles réels
super_manager/manager/employee, et un membre pouvant appartenir à plusieurs projets. - Maintenabilité : minimiser le code de sécurité écrit à la main.
- Continuité : le PIN à 4 chiffres reste le moyen d'identification côté utilisateur.
Options Envisagées
Option A : Consolider la couche d'authentification « maison »
Conserver pin_hash + crypt() et les JWT signés par l'application, en corrigeant les incohérences de rôles.
- Avantage : pas de remigration des comptes.
- Inconvénient : on maintient indéfiniment une brique de sécurité critique réinventée ; surface d'attaque (forge de jeton) ; le hachage manuel duplique ce que Supabase fait déjà.
Option B : Supabase Auth natif (Recommandée)
Utiliser auth.users, signInWithPassword (bcrypt natif géré par Supabase), sessions Supabase natives. Le PIN devient le mot de passe du compte. Rôles réels et pivot project_members (N-N).
- Avantage : hachage/vérification délégués à Supabase, sessions signées standard, RLS branchée sur
auth.uid(), moins de code maison. - Inconvénient : nécessite un nettoyage complet de la base et un re-seed des comptes ; le PIN à 4 chiffres impose un ajustement (cf. ADR 0006).
Décision Retenue
L'Option B : Supabase Auth natif a été retenue.
Justification
C'est la seule option qui supprime la dérive sécuritaire (plus de JWT ni de hachage maison) tout en respectant le brief (rôles réels, multi-projets). Le hachage est délégué à une brique standard, et la RLS s'appuie naturellement sur l'identité auth.uid(). Le surcoût (nettoyage + re-seed) est ponctuel.
Conséquences
Positives
- Aucun code de hachage maison : bcrypt natif Supabase.
- Sessions standard signées par Supabase (plus de JWT forgeable).
- Rôles conformes au brief et multi-projets via
project_members. - Base saine pour la RLS et le contrôle d'accès.