オーラベースのロゴ
オーラベースドキュメント
ドキュメント›ガイド›User impersonation

ユーザーのなりすまし

パスワードを尋ねることなく、ユーザーに代わってサポートとデバッグを行います。 10 分に制限され、セキュリティ ログで厳密に監査されます。

5 分 読み取り·レベル 中間·2026/10/26 に改訂
この翻訳以降、英語のソースが変更されました。一部の情報は古い可能性があります。
このページは自動翻訳されました。英語版が正式です。
#
概要

なりすましとは何ですか?

ユーザーの偽装により、管理者またはサポート エンジニアは、特定のユーザーとして機能する短期間のベアラー トークンを生成できます。これにより、資格情報を要求せずに、顧客のバグの再現、RLS ポリシーのアクセス許可の確認、またはデータの問題のトラブルシューティングが可能になります。

Aurabase の偽装では、次の 3 つの基本的なセキュリティ原則が保証されます。

  1. 有効期間が短い: 偽装トークンは 1 ～ 600 秒間有効です (最大 10 分、デフォルトは 300 秒)。リフレッシュ トークンは決して含まれません。
  2. 明示的なアクター属性: 発行されたアクセス トークンには、誰がセッションを開始したかを示す標準 RFC 8693 act クレームが含まれています。
  3. 発行前監査: アクションは、トークンが生成される前に、行為者、理由、期間、ターゲット ユーザーとともに auth_audit_log に記録されます。ログの挿入が失敗した場合、トークンは発行されません。
#
トークンの要求

RFC 8693 法のクレーム構造

偽装トークンはプロジェクトのアクティブな ES256 キーで署名され、標準のユーザー アクセス トークン形式に準拠し、追加の act (アクター) オブジェクトが含まれます。

デコードされた JWT ペイロードjson
{
  "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: 偽装されるユーザーの ID。 Postgres RLS (auth.uid()) はこの値に評価されます。
  • act.sub: トークンを生成したオペレーターの ID (例: コンソール ユーザー ID または service_role)。
#
HTTP API

管理エンドポイント

偽装には、service_role キーまたは admin ロールを持つオペレーターによる管理者の承認が必要です。

Terminalbash
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
  }'

リクエストボディ

フィールド種類必須説明
reason文字列オプション正当な理由はセキュリティ ログに記録されます。 特権ターゲット アカウント (admin/owner) には が必要です。
ttl_seconds番号オプショントークンの有効期間 (秒単位) (1 ～ 600、デフォルトは 300)。
allow_privilegedブール値オプションターゲット ユーザーが admin または owner ロールを持っている場合は、true に設定する必要があります。

応答 (200 OK)

json
{
  "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"
    }
  }
}
#
SDK

TypeScript SDK

service_role キーで構成された Aurabase クライアントで authAdmin.impersonate() を使用します。

admin-debug.tstypescript
import { createClient } from '@aurabase/aurabase-js'

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

// 5 分間の偽装トークンを生成します
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')

  // このユーザーとしてクエリを実行するための一時的なユーザー クライアントを作成します
  const userClient = createClient(process.env.AURABASE_URL!, process.env.AURABASE_ANON_KEY!, {
    accessToken: data.access_token,
  })

  // クエリはターゲット ユーザーの RLS コンテキストで実行されるようになりました
  const { data: posts } = await userClient.from('posts').select('*')
}
#
セキュリティ

特権アカウントと監査ログ

特権アカウントの保護

管理ロールを持つターゲット アカウント ( role = 'admin'、 role = 'owner'、または 'admin'を含む app_metadata.roles など) は、価値の高いターゲットを表します。偶発的な権限昇格を防ぐには:

  1. allow_privileged: trueを明示的に渡す必要があります。
  2. 空ではない reason 文字列を指定する必要があります。
  3. いずれかのチェックが失敗した場合、バックエンドは 403 Forbiddenでリクエストを拒否します。

セキュリティ監査ログ

すべての偽装イベントは、テナントの auth_audit_log テーブルに挿入されます。

  • アクション: admin_impersonation
  • ユーザーID: 対象ユーザーのID
  • メタデータ: { "actor": "...", "reason": "...", "ttl_seconds": 300, "privileged": false } を含む JSON オブジェクト

この証跡は、Studio › Authentication › Audit logs に表示され、データベース ドレインを介して SIEM ツールに転送できます。