アイデンティティハブ

アイデンティティハブは、Authrimにおけるユーザーアイデンティティ管理の中核コンセプトです。ソーシャルログイン、エンタープライズSSO、パスワードレス認証、Verifiable Credentialsなど、複数のアイデンティティソースを集約し、ユーザーごとに単一の統合アイデンティティとして管理する中央ハブとして機能します。このページでは、コンセプト、ユースケース、主要なメカニズムについて説明します。

課題

現代のアプリケーションはアイデンティティの断片化に直面しています。

複数のログイン方法 — ユーザーはGoogle、Microsoft、GitHub、Email Code、パスキーでサインインする可能性があります。アイデンティティリンクがなければ、各方法が別々のアカウントを作成します。
エンタープライズフェデレーション — 組織は独自のIdP（Okta、Azure AD、Google Workspace）を使用しています。それぞれのオンボーディングにはカスタム連携が必要です。
一貫性のないアクセス制御 — 権限がさまざまなソース（IdPグループ、アプリケーションロール、組織メンバーシップ）から提供され、統一的な評価ポイントがありません。
段階的な信頼 — ソーシャルログインでサインアップしたユーザーは、KYCを完了したりパスキーを登録したユーザーよりもアイデンティティの保証が弱くなります。この段階的な強化をモデル化する標準的な方法がありません。
プライバシーの断片化 — 個人データがプロバイダー間に散在し、同意やデータ削除のための中央ガバナンスがありません。

アイデンティティハブは、すべての外部および内部のアイデンティティソースをリンクし、統一ポリシーを適用し、アプリケーションにパーミッションを配信する単一のアイデンティティレコードを提供することで、これらの課題に対処します。

アーキテクチャ概要

flowchart TB
    subgraph Sources["アイデンティティソース"]
        direction LR
        G["Google"]
        M["Microsoft"]
        GH["GitHub / Apple"]
        S["Enterprise SAML"]
        P["Passkeys"]
        E["Email Code"]
        V["Verifiable Creds"]
    end
    subgraph Federation["フェデレーションレイヤー"]
        direction LR
        PA["プロトコルアダプター<br>(OIDC, SAML, OAuth)"]
        IS["アイデンティティスティッチング"]
        JIT["JITプロビジョニング"]
    end
    subgraph Unified["統合アイデンティティ"]
        UR["統合ユーザーレコード"]
    end
    Sources --> Federation --> Unified
    UR --> PE["ポリシーエンジン<br>(RBAC / ABAC / ReBAC)"]
    subgraph Apps["アプリケーション"]
        direction LR
        A1["アプリA"]
        A2["アプリB"]
        A3["アプリC"]
    end
    PE --> Apps

5つのレイヤー:

アイデンティティソース — 外部IdP、ローカル認証情報、Verifiable Credentials
フェデレーションレイヤー — プロトコルアダプター（OIDC、SAML、OAuth 2.0）がクレームを共通フォーマットに正規化し、アイデンティティスティッチングとJITプロビジョニングを実行
統合アイデンティティ — リンクされた外部アカウント、集約されたクレーム、アイデンティティ保証レベルを持つ単一のユーザーレコード
ポリシーエンジン — 統合アイデンティティに対するRBAC、ABAC、ReBAC評価
アプリケーション — 埋め込みパーミッションと正規化されたクレームを含むトークンを受信

ユースケース

エンタープライズSSO統合

ある組織がエンジニアリング部門にGoogle Workspace、ビジネス部門にMicrosoft Entra IDを使用している場合。アイデンティティハブでは:

両方のIdPがアイデンティティソースとして接続される
どちらのIdPからのユーザーも同じ組織アイデンティティにマッピングされる
SAMLアサーションとOIDCトークンが統一クレームに正規化される
ロール割り当ては個々のIdPからではなく、アイデンティティハブから行われる

これにより、単一のアプリケーションがIdP固有のロジックなしに複数のIdPからのユーザーをサポートできます。

コンシューマー向けソーシャルログイン

コンシューマーアプリケーションがGoogle、GitHub、Appleサインインを提供している場合。最初にGoogleでログインし、後にGitHub（同じメールアドレス）でログインしたユーザーは、2つのアカウントに分かれるべきではありません。

アイデンティティハブはアイデンティティスティッチングを通じてこれを処理します — 検証済みメールアドレスによるアカウントの照合と、同一ユーザーレコードへのリンクです。ユーザーは、複数のリンクされたサインイン方法を持つ単一のアカウントとして認識されます。

B2B SaaSマルチテナンシー

SaaS製品が複数の顧客組織にサービスを提供し、それぞれが独自のIdPを使用している場合:

Acme Corp はOktaをSAMLで使用
Contoso はAzure ADをOIDCで使用
StartupXYZ はGoogle Workspaceを使用

各顧客のIdPはテナント固有のアイデンティティソースとして接続されます。アイデンティティハブは:

初回ログイン時にユーザーをプロビジョニング（JITプロビジョニング）
ユーザーを正しい組織に関連付け
組織固有のロールマッピングを適用
テナントレベルのアクセスポリシーを適用

Progressive Identity（段階的アイデンティティ）

すべてのアイデンティティ保証が同じではありません。アイデンティティハブは段階的な強化をサポートします。

flowchart TB
    L0["Level 0: 匿名セッション"]
    L1["Level 1: ソーシャルログイン<br>プロバイダーによるメール検証済み"]
    L2["Level 2: Email Code検証<br>メール所有権の直接証明"]
    L3["Level 3: パスキー登録<br>デバイスバウンドの暗号化認証情報"]
    L4["Level 4: KYC / Verifiable Credential<br>政府発行の本人確認"]
    L0 --> L1 --> L2 --> L3 --> L4

各レベルはより強いアイデンティティ保証を提供します。アプリケーションは機密性の高い操作に対して最低保証レベルを要求できます — 例えば、金融取引にはLevel 3（パスキー）を要求しつつ、コンテンツ閲覧にはLevel 1（ソーシャルログイン）を許可するなどです。

Verifiable Credentials統合

アイデンティティハブは、OpenID for Verifiable Credentialsプロトコルを通じて**Verifiable Credentials（VC）**をアイデンティティソースとして受け入れることができます。

OpenID4VCI — アイデンティティハブからのクレデンシャル発行
OpenID4VP — 本人確認としてのクレデンシャルプレゼンテーションの受け入れ

VCはprimary login methodではなく、属性証明として扱います。直接的なIdP連携なしに属性検証を可能にします。例えば、ユーザーは政府発行の年齢クレデンシャルを提示して18歳以上であることを証明できます。正確な生年月日や氏名を明かす必要はありません。これらの検証済み属性は統合アイデンティティに追加され、ABACポリシー評価で使用できます。

Credential statusはAdmin APIで管理します。

Endpoint	Method	Purpose
`/api/admin/vc/credentials/:id/revoke`	POST	発行済みcredentialを恒久的にrevoke
`/api/admin/vc/credentials/:id/suspend`	POST	発行済みcredentialを一時停止
`/api/admin/vc/credentials/:id/activate`	POST	一時停止中credentialを再有効化
`/api/admin/vc/status-lists`	GET	credential status list一覧
`/api/admin/vc/status-lists/stats`	GET	status listの利用統計
`/api/admin/vc/status-lists/:id`	GET	status list詳細

主要コンセプト

アイデンティティスティッチング

ユーザーが新しいアイデンティティソースで認証する際、アイデンティティハブは受信アイデンティティが既存ユーザーにリンクできるかをチェックします。

メール照合 — 受信アイデンティティに既存ユーザーと一致する検証済みメールがある場合、アカウントは自動的にリンクされる
明示的リンク — ユーザーはアカウント設定から追加のサインイン方法を手動でリンクできる
競合解決 — あるプロバイダーではメールが検証済みで別のプロバイダーでは未検証の場合、リンクには明示的なユーザー同意が必要

スティッチング後、ユーザーは複数のリンクされた外部アカウントを持つ単一のアイデンティティを持ちます。リンクされた任意の方法で以降のサインインが可能です。

JITプロビジョニング

Just-In-Time（JIT）プロビジョニングは、初回ログイン時にユーザーアカウントを作成します。ユーザーが初めてフェデレーテッドIdPを通じて認証する際:

アイデンティティハブが一致するユーザーが存在するかチェック（アイデンティティスティッチング経由）
一致が見つからない場合、新しいユーザーレコードを作成
IdPからのクレーム（氏名、メール、グループ）をユーザープロファイルにマッピング
IdPマッピング設定に基づいてデフォルトのロールとパーミッションを割り当て
ユーザーは完全にプロビジョニングされ、アプリケーションの使用が可能に

基本的なフェデレーションには事前プロビジョニングやディレクトリ同期は不要です。高度なシナリオでは、SCIMプロビジョニングもサポートされています。

クレーム集約

アイデンティティハブは複数のソースからクレームを集約し、統一プロファイルを構築します。

クレームソース	例	信頼レベル
ソーシャルIdP	氏名、メール、プロフィール画像	中（プロバイダー検証済み）
エンタープライズIdP	メール、グループ、部署	高（組織検証済み）
自己申告	表示名、設定	低（ユーザー提供）
パスキー	デバイスアテステーション	高（暗号化証明）
Verifiable Credential	年齢、国籍、資格	高（発行者証明済み）

ソース間でクレームが競合する場合（例: 異なる表示名）、アイデンティティハブは設定可能な優先順位を適用します。デフォルトでは、信頼度の高いソースが優先されます。

PII分離

アイデンティティソースから収集された個人データは、明示的なstorage sliceを通じてルーティングされます。

DB はcore identityとprotocol dataを保存 — canonical ID、consent、policy、passkeys、custom-claim metadataなど
DB_PII はPIIを含むidentity dataとlinked identitiesを保存
DB_ADMIN はruntime profilesやtenant database registryなどのcontrol-plane dataを保存

tenant-D1デプロイでは、テナント所有の identity_core、identity_pii、関連sliceをtenant database registry経由で生成済みtenant databaseへ解決できます。実装の詳細はPII分離を参照してください。

統一認可

アイデンティティハブは、Authrimの認可システムの基盤として機能します。統合アイデンティティが確立されると、ポリシーエンジンは3つの相補的なモデルを使用してアクセスを評価します。

モデル	基準	例
RBAC	ユーザーに割り当てられたロール	`admin`ロールが`manage:users`パーミッションを付与
ABAC	ユーザー/リソース/環境の属性	部署 = “Engineering” AND 時間 = 営業時間
ReBAC	エンティティ間の関係	ユーザーはリソースを`owns`する組織の`member`

認可決定はトークン（IDトークンおよびアクセストークン）にカスタムクレームとして埋め込まれます。アプリケーションはランタイムにアイデンティティハブに問い合わせることなく、最終的なパーミッションセットを受け取ります。

flowchart TB
    subgraph Hub["アイデンティティハブ"]
        UU["統合ユーザー<br>(リンク済みアカウント)"] --> PE["ポリシーエンジン<br>(RBAC+ABAC+ReBAC)"] --> TC["トークンクレーム<br>(パーミッション)"]
    end
    TC --> JWT["署名済みJWTトークン<br>（パーミッション付き）"]
    JWT --> A["アプリA<br>(トークン検証)"] & B["アプリB<br>(トークン検証)"] & C["アプリC<br>(トークン検証)"]

このアプローチにより、認可決定がリクエスト時ではなくトークン発行時に行われ、ランタイムレイテンシが削減され、アプリケーションが独自のパーミッションストアを維持する必要がなくなります。

次のステップ

ソーシャルログイン — ソーシャルアイデンティティプロバイダーの設定
SAML — エンタープライズSAMLフェデレーション
PII分離 — データベースレベルのPII分離
RBAC — ロールベースアクセス制御の設定
ABAC — 属性ベースアクセス制御ポリシー
ReBAC — Zanzibarスタイルのタプルによるリレーションシップベースアクセス制御