インタビュールーム 認証設計

★登場人物

マルチテナント（OEM）前提で「基盤」「テナント」「エンドユーザー」を分けて捉える。

§認証モデル（委譲信頼）

認証は1種類ではなく2層。分けて捉えないと「他社の参加者をどう認証するか」が分からなくなる。

§トークン種別

「テナント自己署名の参加 JWT → 基盤が検証 → LiveKit アクセストークン」の二段トークン構造。

署名鍵・API key はサーバーに閉じブラウザには出さない。参加 JWT はブラウザに出るが短命でルーム単位にスコープされる。LiveKit の grants（canPublish 等）は基盤だけが書ける — テナントがどんな JWT を署名しても、メディア層の能力は基盤の導出結果に限定される。

§JWT クレーム設計

テナントが自分の鍵で署名するクレーム構成。iss はテナント自身（tenants.uuid）で、鍵解決は (iss, kid) の複合キーで行う。

// Header
{ "alg": "EdDSA", "typ": "JWT", "kid": "t0-2026-07" }

// Payload
{
  "iss": "0190a1a0-...",      // 発行者 = テナント自身（tenants.uuid・表示名ではない）
  "aud": "interview-app",     // 検証側 = 基盤
  "tenant": "t_0",           // テナント識別子
  "room": "room_12345",      // Room の MT 中立 ID（Room 作成時に取得済み）
  "participant": "p_abc123", // 参加者の安定 ID
  "role": "panelist",       // 基盤定義語彙のラベルのみ（capability は載せない）
  "name": "山田太郎",       // サーバー確定の表示名
  "exp": 1730000900,         // 短命（検証側が上限も強制）
  "nbf": 1730000000,
  "jti": "uuid-v4"           // 失効・再生防止
}

§入室フロー（To-Be）

鍵登録 → 発行 → 検証 → 入室の 4 フェーズ。鍵登録はオンボーディング時に 1 回、検証は core への毎リクエストで実行される。入室導線（テナント内認証と role の確定方法）はアクターごとに異なるため、タブで切り替える。パネリストタブが全フェーズを描いた詳細版で、モデレーター・見学者・運用オペレーター・即席調査の各タブは、この図との差分（入室導線と role の確定・grants の違い）だけを描き、共通部分（鍵登録・検証 STEP）は簡略表示している。即席調査は User ドメインを持たない identity 不要の形式で、role を grant トークンから確定する。図中の「基盤」は、テナントからの redirect 先となるインタビュールーム（ルーム SPA）と、検証フェーズを実施する Hono（基盤コア API）の 2 レーンに分けて描く。

パネリスト：リマインドメールの入室 URL（/users/interviews/:id/room）から。テナントが Devise・fixed・本人一致・時間窓を検証して自己署名し、フラグメント付きリダイレクトで受け渡す。検証成功後は入室前設定（音声・画面テスト）→「入室する」で LiveKit トークンを発行する。この図が全アクター共通の詳細版で、他タブはこの図との差分だけを描く。

クリックで拡大 🔍

🖼️ 画面遷移のイメージ：Pencil 共有リンク（入室フローの画面デザイン）

§署名方式

ライブラリは jose を採用（jsonwebtoken は EdDSA 非対応のため）。

公開鍵の保管 — 鍵レジストリ（jwks_keys テーブル）

テナント公開鍵はプッシュ登録で DB（jwks_keys テーブル）に保存する。テナント自己署名では鍵の登録・ローテーションが実行時に発生するため、静的な設定ファイルでは成立しない。検証（(iss, kid) 解決）と JWKS エンドポイントの源泉はこのテーブルに一本化する。鍵レジストリは本方式の信頼のルートそのもの（不正な公開鍵の挿入＝任意発行者のトークン偽造）であり、登録経路は管理画面（/internal/admin）のみに絞り、①登録チャネルの強い認証 ②鍵登録・ローテーション・失効の監査ログ ③可能なら帯域外確認、を必須とする。

// jwks_keys — 公開鍵のみを保存。unique [issuer, kid]（kid 単独解決は禁止）
{
  "issuer": "0190a1a0-...",      // tenants.uuid（基盤自身の鍵は "interview-platform"）
  "kid": "t0-2026-07",
  "alg": "EdDSA",
  "use": "sig",
  "public_jwk": { "kty": "OKP", "crv": "Ed25519", "x": "..." },
  "tenant_id": 0,               // 所有スコープ（基盤自身の鍵は null）
  "active": true
}

鍵ペアの作成 — 管理画面でのブラウザ内生成

テナント署名鍵の鍵ペアは管理画面（/internal/admin）のブラウザ内で WebCrypto により生成する。鍵材料は操作者のブラウザにのみ存在し、基盤のサーバー・ログ・DB を一切通らない（「基盤は検証専用ゲート」の原則を作成フローでも維持する）。openssl / HSM で自前生成するテナント向けには、公開鍵（JWK / SPKI PEM）の貼り付け登録を併設する。

ローテーション — 複数鍵並行有効・一方向遷移

ローテーションは複数鍵の並行有効で無停止に行う。status は active → retiring → revoked の一方向にのみ遷移し（retiring を飛ばした直接 revoke も可）、revoked は終端で復帰できない（再有効化が必要な場合は新規登録として扱う）。

失効の実効遅延は検証側の鍵解決キャッシュ TTL（60 秒）が上限で、revoke 後最大 60 秒で全リクエストに反映される。テナント単位の全停止は、当該テナントの全鍵 revoke で行う。

監査と完全性監視 — 記録・即時通知・照合の3層

鍵レジストリは本方式の信頼のルートそのもの（不正な行挿入＝任意発行者のトークン偽造）であるため、通常の操作ログより強い監査を課す。

§API key との関係

参加 JWT の発行はテナントの署名鍵で完結するため、API key の役割は管理 API（コントロールプレーン）専用になる。