Usurpation d'identité d'utilisateur

L'usurpation d'identité d'utilisateur permet à un administrateur ou à un ingénieur de support de générer un jeton de support de courte durée qui agit en tant qu'utilisateur spécifique. Cela permet de reproduire les bogues des clients, de vérifier les autorisations de la politique RLS ou de résoudre les problèmes de données sans demander d'informations d'identification.

L'usurpation d'identité dans Aurabase garantit trois principes de sécurité fondamentaux :

1. Durée de vie courte: Les tokens d'usurpation d'identité sont valides entre 1 et 600 secondes (10 minutes maximum, 300 secondes par défaut). Ils n'incluent jamais de jeton d'actualisation.
2. Attribution explicite de l'acteur: le jeton d'accès émis porte la revendication standard RFC 8693 act indiquant qui a initié la session.
3. Audit avant émission: L'action est enregistrée dans auth_audit_log avec l'acteur, la raison, la durée et l'utilisateur cible avant que le jeton soit généré. Si l'insertion du journal échoue, aucun jeton n'est émis.

Un jeton d'usurpation d'identité est signé avec la clé ES256 active du projet et est conforme au format standard du jeton d'accès utilisateur, avec un objet act (acteur) supplémentaire :

{
  "sub": "b2f4c3a1-7788-4e89-a5c2-98e3b1234567",
  "project_id": "ecd48fb4-4fe6-48d0-a8cd-f0641ceb8b1c",
  "role": "authenticated",
  "email": "user@example.com",
  "act": {
    "sub": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  },
  "exp": 1730000300,
  "iat": 1730000000,
  "iss": "https://auth-lab-n7qn5stb.localhost:8080/v1/auth"
}

• sub: l'identité de l'utilisateur dont l'identité est usurpée. Postgres RLS (auth.uid()) est évalué à cette valeur.
• act.sub: L'identité de l'opérateur qui a généré le jeton (par exemple, ID utilisateur de la console ou service_role).

L'usurpation d'identité nécessite l'autorisation de l'administrateur via une clé service_role ou un opérateur avec le rôle admin.

curl -X POST "$AURABASE_URL/v1/auth/admin/users/$TARGET_USER_ID/impersonate" \
  -H "apikey: $AURABASE_SERVICE_ROLE_KEY" \
  -H "Authorization: Bearer $AURABASE_SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "Investigating ticket #4812",
    "ttl_seconds": 300,
    "allow_privileged": false
  }'

Corps de la demande

Réponse (200 OK)

{
  "data": {
    "access_token": "eyJhbGciOiJFUzI1NiIsImtpZCI6...",
    "token_type": "Bearer",
    "expires_in": 300,
    "act": {
      "sub": "service_role"
    },
    "user": {
      "id": "b2f4c3a1-7788-4e89-a5c2-98e3b1234567",
      "email": "user@example.com",
      "role": "authenticated"
    }
  }
}

Utilisez authAdmin.impersonate() avec un client Aurabase configuré avec la clé service_role :

import { createClient } from '@aurabase/aurabase-js'

const aura = createClient(process.env.AURABASE_URL!, process.env.AURABASE_SERVICE_ROLE_KEY!)

// Générez un jeton d'usurpation d'identité pendant 5 minutes
const { data, error } = await aura.authAdmin.impersonate('b2f4c3a1-7788-4e89-a5c2-98e3b1234567', {
  reason: 'Reproducing issue reported on dashboard',
  ttlSeconds: 300,
})

if (error) {
  console.error('Failed to impersonate:', error.message)
} else {
  console.log('Impersonation token:', data.access_token)
  console.log('Token expires in:', data.expires_in, 'seconds')

  // Créer un client utilisateur éphémère pour exécuter des requêtes en tant qu'utilisateur
  const userClient = createClient(process.env.AURABASE_URL!, process.env.AURABASE_ANON_KEY!, {
    accessToken: data.access_token,
  })

  // Les requêtes seront désormais exécutées dans le contexte RLS de l'utilisateur cible.
  const { data: posts } = await userClient.from('posts').select('*')
}

Garder les comptes privilégiés

Les comptes cibles qui possèdent des rôles d'administration (tels que role = 'admin', role = 'owner' ou app_metadata.roles contenant 'admin') représentent des cibles de grande valeur. Pour éviter toute élévation accidentelle des privilèges :

1. Vous devez transmettre explicitement allow_privileged: true.
2. Une chaîne reason non vide doit être fournie.
3. Si l’une ou l’autre des vérifications échoue, le backend rejette la demande avec 403 Forbidden.

Journal d'audit de sécurité

Chaque événement d'usurpation d'identité est inséré dans la table auth_audit_log du locataire :

• Action: admin_impersonation
• ID utilisateur: ID de l'utilisateur cible
• Métadonnées: Objet JSON contenant { "actor": "...", "reason": "...", "ttl_seconds": 300, "privileged": false }

Cette piste est visible dans Studio › Authentification › Journaux d'audit et peut être transmise aux outils SIEM via les drains de base de données.