アーキテクチャ

Authrim は、プロトコル処理、管理、DB の配置、拡張機能の実行を複数のサービスに分けています。それらを接続するバインディングとリソースは Setup が生成します。

全体構成

flowchart TB
    Client["アプリとブラウザー"] --> Router["ar-router"]
    Router --> Protocol["認証・プロトコル用 Workers"]
    Router --> Management["ar-management"]
    Protocol --> State["Durable Objects"]
    Protocol --> Lookup["Lookup と検証済みの経路"]
    Lookup --> Data["Core・PII データベース"]
    Management --> Control["ar-control"]
    Control --> Registry["署名付きランタイムレジストリ"]
    Registry --> Lookup
    Protocol --> Plugins["ar-plugin-runner"]

Worker・領域	役割
`ar-router`	Service Bindings による公開リクエストの振り分けと共通処理
`ar-discovery`	OIDC Discovery と JWKS
`ar-auth`	認可エンドポイント、ログイン、同意、認証フロー
`ar-token`・`ar-userinfo`	トークン発行・操作と UserInfo
`ar-async`	Device Authorization と CIBA。すべてのバックグラウンドジョブを担当するわけではありません
`ar-saml`・`ar-bridge`	SAML IdP/SP と外部 ID プロバイダー連携
`ar-management`	管理 API と運用処理
`ar-policy`・`ar-vc`	ポリシー評価とクレデンシャルの発行・検証経路
`ar-control`	配置、容量、署名付きレジストリの公開
`ar-plugin-runner`	スコープを限定したプラグイン実行、通知配送、フック処理
`ar-admin-ui`・`ar-login-ui`	管理画面とユーザー向け画面

Lookup のルーティングは共通サービスに実装し、アカウントディレクトリの調整には ar-management の名前付き RPC エントリーポイントを使います。独立した ar-lookup Worker ではありません。

ar-lib-core は共通の型、リポジトリ、ルーティング、プロトコル状態のサービスを提供します。ライブラリと、運用上の役割を担って別々にデプロイされる Worker は区別してください。

ストレージ構成

Core・PII・Admin・Control・Lookup・Plugin Runner は別のスキーマとして管理します。テナントのメタデータとアカウントのデータが異なる保存先になる場合があり、一つの環境に複数のアカウント用シャードを持てます。

D1 の配置は Control Plane が管理します。ランタイムレジストリは役割、シャード、バインディング、データ所在地の区分、世代で保存先を識別します。アカウントの検索ではブラインドインデックスを使い、Core と PII の両方の保存先を解決します。署名付きの経路を検証し、接続先のメタデータも再確認します。不正な経路を共有データで代用することはありません。

現在のランタイムプロファイルは audit と residency です。旧来の shared-d1・tenant-d1・external-durable は、現在のアカウント保存先の指定方法ではありません。テナント DB のリゾルバーは D1 を受け付けます。別の箇所に外部 SQL アダプターがあっても、アカウントの経路をそのまま差し替えられるわけではありません。

テーブル構造、機微な値の読み出し、削除の挙動は PII 分離を参照してください。

Durable Objects の状態とシャーディング

Durable Objects は、セッション、認可コード、リフレッシュトークンのローテーション、チャレンジ、レート制限、PAR、リプレイ検出などの状態を調整します。D1 への永続化やミラーは各サービスの実装によります。これらを一つの汎用キャッシュ階層としては扱いません。

Setup の authCodeShards、refreshTokenShards、sessionShards、challengeShards は、それぞれ既定値が 4 です。これは各状態サービスの設定であり、D1 のアカウント DB 数ではありません。シャード構成の変更には、そのサービスに対応する経路とライフサイクルの扱いが必要です。

配置と容量

Control は管理対象 DB の容量と配置を追跡します。共有プールとテナント専用配置は別のポリシーです。経路には接続先と世代が含まれるため、容量の変更はバインディング名の変更だけでは完結しません。

Worker の配置、Durable Object の配置、DB のデータ所在地、ストレージの分離は別の選択です。location hint を指定しても、ログイン全体が一つの地域で実行される保証にはなりません。

キャッシュと非同期処理

KV には設定、キャッシュ、署名付きランタイム情報を保存します。利用側は必要な識別情報や世代を確認してから経路を使います。プロセス内キャッシュは高速化の手段であり、永続的な正本ではありません。

Queues、スケジュール処理、永続的な操作状態、outbox は用途が異なります。例えば Plugin Runner は再試行状態を持つ非同期フックを処理し、Management と Control にも独自の定期処理があります。ar-async をすべてのジョブの実行役として捉えないでください。

導入と更新

Setup がデプロイ設定とリリースごとのマイグレーション計画を管理します。ベースラインは空の DB 向けで、既存環境には対応する更新計画を使います。古いルート直下の SQL 一覧を手動適用して構成を作り直さないでください。インストールに手順をまとめています。

関連する説明はマルチテナンシー、エッジコンピューティング、プラグインを参照してください。