Authentification

Chaque requête authentifiée vers GCM transporte un JSON Web Token (JWT) signé par Supabase Auth. Le token a trois rôles :

1. Identifier l'utilisateur (claim sub).
2. Identifier l'organisation à laquelle il appartient (claim organization_id, défini par notre auth hook).
3. Transporter les claims de rôle/permission utilisés par les politiques de sécurité au niveau des lignes dans la base de données.

Obtenir un token

En tant qu'utilisateur final (dans le navigateur)

L'application le fait pour vous. Lorsque vous vous connectez sur /auth, le SDK stocke le token dans localStorage et le rafraîchit automatiquement.

Par programmation (pour les scripts, CI, intégrations)

Utilisez le password grant de Supabase :

curl -X POST 'https://fzdacujgoluefgfbmren.supabase.co/auth/v1/token?grant_type=password' \
  -H 'apikey: YOUR_ANON_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"email":"you@church.org","password":"…"}'

Réponse :

{
  "access_token": "eyJhbGc…",
  "expires_in": 3600,
  "refresh_token": "vN9XzL…",
  "token_type": "bearer"
}

À l'intérieur du token

Décodez le access_token (base64url du segment du milieu) et vous verrez :

{
  "sub": "9a3b…",
  "email": "you@church.org",
  "role": "authenticated",
  "organization_id": "de00…",
  "is_platform_admin": false,
  "is_superadmin": false,
  "exp": 1782385294
}

Ne faites pas confiance à ces claims côté client

N'importe qui peut forger un JWT avec des claims arbitraires. La base de données ne fait confiance qu'à ce que Supabase signe. Si votre code client prend des décisions d'autorisation, traitez-les comme des indices UX — la vraie vérification se fait sur le serveur.

Rafraîchissement

Le token d'accès vit une heure. Quand il expire, échangez-le contre un nouveau :

curl -X POST 'https://fzdacujgoluefgfbmren.supabase.co/auth/v1/token?grant_type=refresh_token' \
  -H 'apikey: YOUR_ANON_KEY' \
  -d '{"refresh_token":"…"}'

Tokens service-role

La clé service_role contourne complètement la sécurité au niveau des lignes. Elle existe pour les migrations, les tâches cron et les intégrations backend qui ont besoin d'agir entre organisations. Ne l'envoyez jamais à un navigateur et ne la commitez pas dans le contrôle de version. Nous l'utilisons uniquement côté serveur — dans les edge functions via Deno.env.get('SUPABASE_SERVICE_ROLE_KEY'), jamais via HTTP.

Accès multi-organisation

Un seul utilisateur auth (sub) peut appartenir à plusieurs organisations en ayant plusieurs lignes profiles — une par organisation. L'organisation active est sélectionnée à la connexion (ou mémorisée via un cookie). L'auth hook injecte le organization_id actif dans le JWT, pour que la base de données limite correctement.

Changer d'organisation dans l'interface déclenche un rafraîchissement du token.