Autenticación

Cada solicitud autenticada a GCM lleva un JSON Web Token (JWT) firmado por Supabase Auth. El token tiene tres trabajos:

1. Identificar al usuario (claim sub).
2. Identificar a qué organización pertenece (claim organization_id, establecido por nuestro auth hook).
3. Llevar los claims de rol/permiso usados por las políticas de seguridad a nivel de fila en la base de datos.

Obtener un token

Como usuario final (en el navegador)

La aplicación hace esto por ti. Cuando inicias sesión en /auth, el SDK almacena el token en localStorage y lo refresca automáticamente.

Programáticamente (para scripts, CI, integraciones)

Usa el 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":"…"}'

Respuesta:

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

Dentro del token

Decodifica el access_token (base64url del segmento del medio) y verás:

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

No confíes en estos claims del lado del cliente

Cualquiera puede crear un JWT con claims arbitrarios. La base de datos confía solo en lo que firma Supabase. Si tu código del cliente toma decisiones de autorización, trátalas como pistas de UX — la verificación real ocurre en el servidor.

Refresco

El access token vive una hora. Cuando expira, intercámbialo por uno nuevo:

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

Tokens de service-role

La clave service_role omite por completo la seguridad a nivel de fila. Existe para migraciones, trabajos cron e integraciones de backend que necesitan actuar entre organizaciones. Nunca la envíes a un navegador ni la subas al control de versiones. La usamos solo del lado del servidor — en edge functions a través de Deno.env.get('SUPABASE_SERVICE_ROLE_KEY'), nunca por HTTP.

Acceso multi-organización

Un solo usuario de auth (sub) puede pertenecer a varias organizaciones teniendo múltiples filas en profiles — una por organización. La organización activa se selecciona al iniciar sesión (o se recuerda mediante cookie). El auth hook inyecta el organization_id activo en el JWT, para que la base de datos limite correctamente.

Cambiar de organización en la UI dispara un refresco del token.