Benutzeridentitätsbetrug

Der Benutzeridentitätswechsel ermöglicht es einem Administrator oder Supporttechniker, ein kurzlebiges Inhabertoken zu generieren, das als bestimmter Benutzer fungiert. Dadurch ist es möglich, Kundenfehler zu reproduzieren, RLS-Richtlinienberechtigungen zu überprüfen oder Datenprobleme zu beheben, ohne Anmeldeinformationen anzufordern.

Der Identitätswechsel in Aurabase garantiert drei grundlegende Sicherheitsprinzipien:

1. Kurze Lebensdauer: Identitätswechsel-Tokens sind zwischen 1 und 600 Sekunden gültig (maximal 10 Minuten, Standard 300 Sekunden). Sie enthalten niemals ein Aktualisierungstoken.
2. Explizite Akteurszuordnung: Das ausgestellte Zugriffstoken trägt den standardmäßigen RFC 8693-Anspruch act, der angibt, wer die Sitzung initiiert hat.
3. Audit-before-issuance: Die Aktion wird in auth_audit_log mit dem Akteur, dem Grund, der Dauer und dem Zielbenutzer aufgezeichnet, bevor das Token jemals generiert wird. Wenn das Einfügen des Protokolls fehlschlägt, wird kein Token ausgegeben.

Ein Identitätswechseltoken wird mit dem aktiven ES256-Schlüssel des Projekts signiert und entspricht dem Standardformat für Benutzerzugriffstoken mit einem zusätzlichen act (Akteur)-Objekt:

{
  "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: Die Identität des Benutzers, der imitiert wird. Postgres RLS (auth.uid()) ergibt diesen Wert.
• act.sub: Die Identität des Operators, der das Token generiert hat (z. B. Konsolenbenutzer-ID oder service_role).

Der Identitätswechsel erfordert eine Administratorautorisierung über einen service_role-Schlüssel oder einen Operator mit der Rolle 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
  }'

Anforderungstext

Antwort (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"
    }
  }
}

Verwenden Sie authAdmin.impersonate() mit einem Aurabase-Client, der mit dem Schlüssel service_role konfiguriert ist:

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

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

// Generieren Sie 5 Minuten lang ein Identitätswechsel-Token
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')

  // Erstellen Sie einen kurzlebigen Benutzerclient, um Abfragen als dieser Benutzer auszuführen
  const userClient = createClient(process.env.AURABASE_URL!, process.env.AURABASE_ANON_KEY!, {
    accessToken: data.access_token,
  })

  // Abfragen werden jetzt im RLS-Kontext des Zielbenutzers ausgeführt
  const { data: posts } = await userClient.from('posts').select('*')
}

Schutz privilegierter Konten

Zielkonten, die über Administratorrollen verfügen (z. B. role = 'admin', role = 'owner' oder app_metadata.roles mit 'admin'), stellen hochwertige Ziele dar. So verhindern Sie eine versehentliche Rechteerweiterung:

1. Sie müssen allow_privileged: true explizit übergeben.
2. Es muss eine nicht leere Zeichenfolge reason bereitgestellt werden.
3. Wenn eine der Prüfungen fehlschlägt, lehnt das Backend die Anfrage mit 403 Forbidden ab.

Sicherheitsüberwachungsprotokoll

Jedes Identitätswechselereignis wird in die Tabelle auth_audit_log des Mandanten eingefügt:

• Aktion: admin_impersonation
• Benutzer-ID: ID des Zielbenutzers
• Metadaten: JSON-Objekt, das { "actor": "...", "reason": "...", "ttl_seconds": 300, "privileged": false } enthält

Dieser Trail ist in Studio › Authentifizierung › Audit-Protokolle sichtbar und kann über Datenbankabläufe an SIEM-Tools weitergeleitet werden.