Authentification partagée

Statut

Document de cadrage écosystème — v1.0 — relu le 2026-05-10.

Vue d'ensemble

L'authentification dans l'écosystème DMV repose sur deux mécanismes complémentaires :

1. Supabase Auth : authentification des utilisateurs côté frontend (email/password, OAuth).
2. Laravel Sanctum : tokens d'accès API émis par le backend après validation du JWT Supabase.

Flux d'authentification

Frontend → Supabase Auth → JWT Supabase
JWT Supabase → POST /api/v1/auth/exchange → Token Sanctum
Token Sanctum → Requêtes API protégées (Authorization: Bearer)

Étapes détaillées

1. L'utilisateur s'authentifie sur le frontend via Supabase Auth.
2. Le frontend reçoit un JWT Supabase (supabase_token).
3. Le frontend envoie ce JWT à POST /api/auth/exchange avec le header X-App-Source.
4. Le backend valide le JWT via SupabaseTokenService (bibliothèque firebase/php-jwt).
5. Le backend trouve ou crée le profil applicatif (Profile).
6. Le backend émet un token Sanctum et retourne { token, token_type, user }.
7. Le frontend stocke le token Sanctum et l'utilise pour toutes les requêtes API.

Endpoints d'authentification

Méthode	Route	Rôle
POST	/api/v1/auth/exchange	Échange JWT Supabase → token Sanctum
GET	/api/v1/auth/me	Retourne le CurrentUser authentifié
POST	/api/v1/auth/logout	Révoque le token Sanctum courant

Header X-App-Source

Toutes les requêtes authentifiées doivent inclure le header X-App-Source identifiant l'application cliente.

Sources acceptées :

Valeur	Application
dmv	Application publique dmv-public (Next.js)
backoffice	Backoffice d'administration
playloop	Application PlayLoop
assosuite	Application AssoSuite
mairie	Application Mairie

Ce header conditionne le périmètre de certaines réponses (scope des publications, permissions contextuelles).

Authentification PlayLoop (device)

Les devices PlayLoop (écrans) utilisent un mécanisme différent : token opaque device.

• Endpoint : Authorization: Bearer {device_token}
• Middleware : device.token
• Le token est validé par DeviceTokenService et le device est injecté dans la requête.

Il n'y a pas d'utilisateur Supabase pour un device PlayLoop.

Sécurité

• Les JWT Supabase sont validés avec la clé secrète SUPABASE_JWT_SECRET.
• Les tokens Sanctum peuvent avoir une expiration configurable (sanctum.expiration).
• Un token révoqué (logout) ne peut plus être utilisé.
• Ne jamais exposer SUPABASE_JWT_SECRET ni les tokens dans les logs.

État actuel vs cible

Aspect	État actuel	Cible
Auth utilisateur	Supabase → Sanctum	Idem
Auth device	Token opaque	Idem + rotation automatique
Expiration tokens	Configurable	Politique définie par app
Révocation	Manuel (logout)	Révocation par session
Multi-sessions	Non géré	Sessions nommées par appareil

Points à clarifier

• Durée de vie standard des tokens par application.
• Stratégie de rotation des tokens device PlayLoop.
• Gestion des tokens expirés côté frontend (refresh ou re-authentification).
• Audit log des connexions et révocations.