Aller au contenu principal

Authentification

Statut​

Document de cadrage sécurité — version initiale.

Objectif​

L'authentification doit établir de manière fiable qui appelle l'écosystème DMV : utilisateur, administrateur, acteur rattaché, mairie, association ou device PlayLoop.

Elle doit rester séparée de l'autorisation, qui décide ensuite ce que l'identité authentifiée peut faire.

État actuel visible​

Le code montre :

  • Laravel Sanctum dans l'API ;
  • une configuration SANCTUM_TOKEN_EXPIRATION ;
  • un service SupabaseTokenService qui valide les JWT Supabase avec firebase/php-jwt ;
  • une exigence de secret SUPABASE_JWT_SECRET pour valider les tokens Supabase ;
  • un contrôle du rôle JWT Supabase authenticated ;
  • des usages Supabase Auth côté frontends ;
  • un middleware PlayLoop qui lit Authorization: Bearer {token} pour authentifier un device ;
  • des routes protégées par auth:sanctum dans les modules backend.

Sources d'identité​

SourceÉtatRôle
Supabase AuthVisible côté frontends et validation JWT côté APIAuthentification historique ou actuelle à rationaliser.
Laravel SanctumVisible côté APIProtection des routes API et tokens applicatifs.
Token device PlayLoopVisible côté backendAuthentification de terminaux d'affichage.
StripeVisible pour webhooksAuthentification par signature webhook, pas par session utilisateur.

Principes​

  • Ne jamais considérer le frontend comme source de vérité des droits.
  • Ne pas confondre le rôle Supabase authenticated avec un rôle métier DMV.
  • Refuser les tokens expirés, invalides ou signés avec un secret inconnu.
  • Ne jamais exposer SUPABASE_JWT_SECRET, STRIPE_SECRET ou STRIPE_WEBHOOK_SECRET.
  • Prévoir une révocation claire des tokens utilisateurs et devices.
  • Utiliser des réponses JSON cohérentes pour les erreurs d'authentification.

Flux cible​

La cible doit clarifier le flux d'authentification principal :

  1. L'utilisateur s'authentifie via le frontend autorisé.
  2. Le backend vérifie ou échange le token d'identité.
  3. L'API associe l'identité à un profil applicatif DMV.
  4. Les routes protégées utilisent une authentification backend contrôlée.
  5. Les autorisations métier sont évaluées séparément.

Ce flux reste à stabiliser précisément entre Supabase Auth et Sanctum.

Authentification PlayLoop​

PlayLoop utilise un besoin différent : authentifier un écran ou device, pas seulement un utilisateur.

Le middleware visible :

  • lit un bearer token ;
  • valide le token via un service dédié ;
  • refuse les tokens manquants, invalides ou révoqués ;
  • injecte le device dans la requête si la validation réussit.

La cible doit documenter le cycle de vie complet : création, affichage initial, rotation, révocation, expiration et remplacement d'un device.

Webhooks Stripe​

Le webhook Stripe est public par conception mais protégé par signature.

Le code visible :

  • exclut la route webhook de Sanctum et identify.app ;
  • valide immédiatement la signature Stripe ;
  • dispatche ensuite le traitement en queue ;
  • revalide la signature dans le job.

Ce modèle est cohérent avec un endpoint webhook public, à condition que le secret webhook soit protégé.

Vision cible​

  • Choisir et documenter le flux canonique entre Supabase Auth et Sanctum.
  • Définir les durées d'expiration selon le type de token.
  • Ajouter une stratégie de révocation et rotation.
  • Encadrer les sessions administratives plus strictement que les sessions publiques.
  • Étudier une authentification renforcée pour les comptes sensibles.

Points à clarifier​

  • Source d'authentification officielle à long terme.
  • Format et durée des tokens émis par l'API.
  • Politique MFA pour admins, mairies et comptes sensibles.
  • Gestion des sessions multi-applications.
  • Procédure de révocation d'urgence.