Aller au contenu principal

ADR-003 — Supabase Auth comme provider d’authentification

Statut​

Proposed

Date​

2026-05-10

Contexte​

Faits visibles et contexte validé :

  • des usages Supabase Auth sont visibles côté frontends ;
  • le backend Laravel contient aussi des éléments liés à Sanctum et Firebase JWT ;
  • le projet distingue utilisateurs, acteurs, communes, rôles et permissions ;
  • les accès directs Supabase côté frontend existent historiquement et doivent être rationalisés progressivement ;
  • la cible stratégique est que la logique métier sensible passe par Laravel.

Objectif :

  • clarifier le rôle de Supabase Auth comme provider d’identité, sans confondre authentification et autorisation métier.

Décision​

DMV propose d’utiliser Supabase Auth comme provider d’authentification central pour l’identité utilisateur, sous réserve de validation technique et sécurité complète.

Cette décision ne signifie pas que Supabase doit porter toute la logique métier.

Répartition cible :

DomaineResponsabilité
AuthentificationSupabase Auth comme provider d’identité.
Autorisation métierAPI Laravel, RBAC, scopes et règles backend.
Données sensiblesAccès contrôlés par backend Laravel.
FrontendsConsommation de sessions/tokens validés, sans logique sensible dispersée.

Conséquences​

Effets attendus :

  • accélération de l’authentification utilisateur ;
  • mutualisation possible des sessions entre applications ;
  • réduction de complexité sur la gestion bas niveau des comptes.

Contraintes :

  • valider précisément le flux entre Supabase Auth et Laravel ;
  • contrôler les tokens côté backend ;
  • documenter la migration des accès directs historiques ;
  • ne pas déléguer le RBAC métier complet au frontend.

Alternatives envisagées​

AlternativeRaison de non-priorisation
Authentification 100 % Laravel SanctumPlus de contrôle, mais plus de charge d’implémentation multi-apps.
Firebase AuthPrésence d’éléments JWT, mais provider central non confirmé comme choix cible.
Provider SSO externe dédiéPotentiellement utile plus tard, mais prématuré à ce stade.

Risques​

  • Confusion entre identité, rôles et droits métier.
  • Couplage fort à Supabase si la stratégie de migration n’est pas documentée.
  • Incohérences entre sessions frontend et validations backend.

Liens associés​

  • docs/10-security/02-authentication.md
  • docs/10-security/03-authorization.md
  • docs/10-security/05-rls.md
  • docs/07-backend/11-authentication.md