Aller au contenu principal

Authentification et RBAC

Flux d'authentification et de contrôle d'accès pour l'API Laravel DMV : de l'identité utilisateur à la ressource protégée.

Statut​

  • Supabase Auth côté frontends, validation JWT côté API, Sanctum : actifs et confirmés dans le code.
  • Middlewares ensure.admin, mairie.access, asso.access, device.token : actifs.
  • Policies Laravel sur acteurs et publications : actives.
  • MFA, flux canonique Supabase/Sanctum stabilisé : à définir (vision cible).
  • Flèches pointillées -.-> : chemin alternatif (Device PlayLoop).

Schéma​

Lecture du schéma​

Flux utilisateur standard : l'utilisateur s'authentifie via Supabase Auth (côté frontend). L'API valide le JWT avec firebase/php-jwt en vérifiant SUPABASE_JWT_SECRET et le rôle authenticated. Un token Sanctum est émis avec une durée de vie configurable (SANCTUM_TOKEN_EXPIRATION).

Middleware chain :

  1. identify.app identifie l'application source via l'en-tête X-App-Source. Ce header contextualise la requête mais ne suffit pas à autoriser une action.
  2. auth:sanctum vérifie que le token est valide et non expiré.
  3. La vérification de rôle applique le middleware adapté (ensure.admin, mairie.access, asso.access) selon la route.
  4. La policy Laravel contrôle l'accès à la ressource spécifique selon la propriété ou le périmètre.

RBAC rôle + périmètre : un rôle seul ne suffit pas. L'accès combine toujours un rôle (utilisateur, contributeur, mairie, admin) et un périmètre (acteur, commune, association, global).

Device PlayLoop : les devices ne passent pas par Supabase Auth. Ils utilisent un token opaque via le middleware device.token (Bearer {token}) et rejoignent la chaîne à partir de identify.app.

Refus : les erreurs d'autorisation retournent une réponse JSON structurée en 401 (non authentifié) ou 403 (non autorisé).