Aller au contenu principal

Flux d’authentification

Objectif du flux

Identifier un utilisateur, rattacher sa requête à une application source et préparer les contrôles d’autorisation côté Laravel.

Acteurs/systèmes impliqués

  • Utilisateur final ou administrateur.
  • Frontend DMV, backoffice, PlayLoop, AssoSuite ou Mairie.
  • Provider d’authentification à confirmer selon le flux.
  • API Laravel.
  • Middleware identify.app.
  • Services d’autorisation / RBAC.

Étapes principales

  1. L’utilisateur s’authentifie via le mécanisme disponible côté application.
  2. Le frontend transmet un token ou une session exploitable par l’API.
  3. Le frontend ajoute le header X-App-Source.
  4. Laravel identifie l’application source.
  5. Laravel valide l’identité utilisateur.
  6. Laravel charge les rôles, permissions et périmètres nécessaires.
  7. La requête est autorisée ou refusée avant d’atteindre la logique métier sensible.
  8. Les actions sensibles sont journalisées.

Données manipulées

  • Identifiant utilisateur.
  • Token ou session d’authentification.
  • Source applicative : dmv, backoffice, playloop, assosuite, mairie.
  • Rôles et permissions.
  • Périmètres : utilisateur, acteur, commune, app ou administration.

Règles sécurité

  • Le header X-App-Source ne doit pas suffire à autoriser une action.
  • Les permissions doivent être validées côté Laravel.
  • Les frontends ne doivent pas décider seuls des droits métier.
  • Les tokens doivent être vérifiés avant accès aux données sensibles.
  • Les actions administratives doivent être auditables.

Erreurs/points de vigilance

  • Token absent, expiré ou invalide.
  • Source applicative absente ou non reconnue.
  • Rôle insuffisant pour l’action demandée.
  • Confusion entre authentification et autorisation.
  • Flux confirmé dans le code : Supabase JWT → POST /api/v1/auth/exchange → token Sanctum. Pas de Firebase.

État actuel vs cible

SujetÉtat actuel visibleVision cible
AuthSupabase Auth côté frontends ; échange JWT Supabase → token Sanctum via SupabaseTokenService. Pas de Firebase.Flux stabilisé et documenté.
App sourceMiddleware identify.app basé sur X-App-Source.App source utilisée comme contexte, jamais comme preuve d’autorisation seule.
RBACRôles et permissions documentés.RBAC rôle + scope appliqué systématiquement côté API.

Diagramme Mermaid

TODO / points à confirmer

  • Provider d’authentification cible pour chaque app.
  • Format exact des tokens acceptés par Laravel.
  • Règles de renouvellement de session.
  • Matrice officielle rôles/scopes/actions.