Podszywanie się pod użytkownika

Podszywanie się pod użytkownika umożliwia administratorowi lub inżynierowi pomocy technicznej wygenerowanie krótkotrwałego tokena okaziciela, który działa jako konkretny użytkownik. Umożliwia to odtwarzanie błędów klientów, sprawdzanie uprawnień zasad RLS lub rozwiązywanie problemów z danymi bez żądania poświadczeń.

Podszywanie się pod Aurabase gwarantuje trzy podstawowe zasady bezpieczeństwa:

1. Krótki czas życia: Tokeny personifikacji są ważne od 1 do 600 sekund (maksymalnie 10 minut, domyślnie 300 sekund). Nigdy nie zawierają tokena odświeżania.
2. Jawne przypisanie aktora: Wystawiony token dostępu zawiera standardowe oświadczenie RFC 8693 act wskazujące, kto zainicjował sesję.
3. Audyt przed wydaniem: Akcja jest rejestrowana w auth_audit_log z aktorem, przyczyną, czasem trwania i użytkownikiem docelowym przed wygenerowaniem tokenu. Jeśli wstawienie dziennika nie powiedzie się, nie zostanie wydany żaden token.

Token personifikacji jest podpisany aktywnym kluczem ES256 projektu i jest zgodny ze standardowym formatem tokena dostępu użytkownika, z dodatkowym obiektem act (aktor):

{
  "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: Tożsamość użytkownika, pod którego się podszywasz. Postgres RLS (auth.uid()) oblicza tę wartość.
• act.sub: Tożsamość operatora, który wygenerował token (np. identyfikator użytkownika konsoli lub service_role).

Podszywanie się wymaga autoryzacji administratora poprzez klucz service_role lub operatora z rolą 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
  }'

Treść żądania

Odpowiedź (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"
    }
  }
}

Użyj authAdmin.impersonate() z klientem Aurabase skonfigurowanym z kluczem service_role:

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

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

// Wygeneruj token personifikacji na 5 minut
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')

  // Utwórz tymczasowego klienta użytkownika, aby uruchamiać zapytania jako ten użytkownik
  const userClient = createClient(process.env.AURABASE_URL!, process.env.AURABASE_ANON_KEY!, {
    accessToken: data.access_token,
  })

  // Zapytania będą teraz wykonywane w kontekście RLS użytkownika docelowego
  const { data: posts } = await userClient.from('posts').select('*')
}

Ochrona kont uprzywilejowanych

Konta docelowe posiadające role administracyjne (takie jak role = 'admin', role = 'owner' lub app_metadata.roles zawierające 'admin') reprezentują cele o dużej wartości. Aby zapobiec przypadkowemu podniesieniu uprawnień:

1. Musisz jawnie przekazać allow_privileged: true.
2. Należy podać niepusty ciąg reason.
3. Jeśli którekolwiek sprawdzenie zakończy się niepowodzeniem, backend odrzuca żądanie za pomocą 403 Forbidden.

Dziennik audytu bezpieczeństwa

Każde zdarzenie personifikacji jest wstawiane do tabeli auth_audit_log dzierżawy:

• Akcja: admin_impersonation
• Identyfikator użytkownika: Identyfikator użytkownika docelowego
• Metadane: Obiekt JSON zawierający { "actor": "...", "reason": "...", "ttl_seconds": 300, "privileged": false }

Ten ślad jest widoczny w Studio > Uwierzytelnianie > Dzienniki audytu i może zostać przekazany do narzędzi SIEM poprzez drenaż baz danych.