コンテンツにスキップ
Authrim

アーキテクチャ

Authrimは、Cloudflare Workersエコシステム上に構築された統合アイデンティティ＆アクセスプラットフォームです。このページでは、マルチワーカーシステム、Service Bindings router、ランタイムストレージプロファイル、テナントDBルーティング、Durable Objectの状態管理について解説します。

システム概要

Authrimは、Service Bindingsで接続された複数の専門Workerで構成されています。ar-router Workerが中央のエントリーポイントとして機能し、ドメイン固有のWorkerにリクエストを振り分けます。

flowchart LR
    router["ar-router
(エントリーポイント)"]
    subgraph endpoints["OIDC / Auth"]
        discovery["ar-discovery
(OIDCメタ)"]
        auth["ar-auth
(認可EP)"]
        token["ar-token
(トークンEP)"]
        userinfo["ar-userinfo
(UserInfo EP)"]
    end
    subgraph federation["フェデレーション"]
        saml["ar-saml
(SAML IdP)"]
        bridge["ar-bridge
(外部IdP)"]
    end
    subgraph ops["運用"]
        mgmt["ar-management
(管理API)"]
        async["ar-async
(バックグラウンド処理)"]
        policy["ar-policy
(Policy)"]
        vc["ar-vc
(VC)"]
    end
    router --> discovery & auth & token & userinfo
    router --> saml & bridge
    router --> mgmt & async & policy & vc
Worker役割
ar-routerリクエストルーティング、レート制限、CORS
ar-discovery/.well-known/openid-configuration、JWKS
ar-auth認可エンドポイント、同意、ログインフロー
ar-tokenトークンエンドポイント（コード交換、リフレッシュ、デバイス）
ar-userinfoUserInfoエンドポイント
ar-management管理API（ユーザー、クライアント、ロール、ポリシー）
ar-samlSAML IdPおよびSP
ar-bridge外部IdP連携（ソーシャルログイン、エンタープライズSSO）
ar-asyncバックグラウンドジョブ（鍵ローテーション、クリーンアップ、SCIM sync）
ar-policyポリシー評価と認可チェック
ar-vcVerifiable Credential issuer/verifierサーフェス

すべてのWorkerは共通ライブラリ ar-lib-core を共有しており、データベース抽象化、リポジトリ、ユーティリティ、Durable Objectの定義を提供します。

ストレージアーキテクチャ

AdapterとResolverのスタック

Authrimはストレージアクセスをadapter、runtime profile、resolverに分離しています。目的は、テナント設定に生のインフラbindingや認証情報を保存せず、複数のデプロイ形態に対応することです。

type StorageDeploymentProfile = 'shared-d1' | 'tenant-d1' | 'external-durable';
type StorageDriver = 'd1' | 'postgres' | 'mysql';

主な層は以下です。

  • Database adapters: Cloudflare D1や外部SQL adapterなどの具体的なbackendをラップ
  • Runtime profiles: 各logical sourceやstorage sliceの保存先を記述
  • Storage target resolvers: profile targetを環境binding、connection reference、tenant database resolverへ解決
  • Tenant database registry: DB_ADMIN と任意の署名済み TENANT_RUNTIME_REGISTRY snapshotからtenant-D1 targetを解決

デプロイ単位のD1 binding

デフォルトの builtin:storage:shared-d1 プロファイルは3つのデプロイ単位D1 bindingを使います。

Binding目的代表的な内容
DBCore identityとprotocol dataOAuth/OIDC clients、consent、policy data、passkeys、canonical identity graph rows、custom-claim metadata、transient auth persistence
DB_PIIPIIを含むidentity dataidentity_sensitive_values、legacy users_pii、linked identities、subject identifiers、tombstones、PII audit data
DB_ADMINControl planeとadmin dataAdmin users/RBAC、runtime profiles、tenant database registry、audit/logging control data、jobs

新規インストールではcore、PII、admin migrationを別々に適用します。

  • migrations/001_core_foundation.sql から最新のcore migration
  • migrations/pii/001_pii_schema.sql
  • migrations/admin/001_admin_users_rbac_security.sql から最新のadmin migration

ランタイムストレージプロファイル

Storage profileは、テナント設定にsecretを埋め込まずにlogical sourceとsliceをルーティングします。

ProfileDeployment Profile現在の役割
builtin:storage:shared-d1shared-d1デフォルトのデプロイ単位 DB / DB_PII / DB_ADMIN 分離
builtin:storage:tenant-d1tenant-d1control dataは共有し、テナント所有のcore/PII/audit sliceをtenant database registryで解決
builtin:storage:external-durableexternal-durable選択されたplane向けの外部durable storage profile。route capability checkでガード
builtin:storage:external-postgres外部SQL例対応済みuser/custom/PII sliceにconnection referenceを使用

主なlogical sourceとstorage sliceは以下です。

Source / Slice意味
controlAdmin/control-plane data。通常は DB_ADMIN
identity_core標準化された非PII identity graphとprotocol data
identity_pii / custom_piisensitive identity values、legacy user PII、custom fields
transient_authDurable Objectsが主に所有するauth stateのcold persistence/mirror
auditAudit/logging runtimeとcontrol data
custom_claims / registration_fieldsCustom claim schemaとfield storage
policy / authorizationPolicy、consent、authorization関連state
passkeys / linked_identitiesPasskeyとlinked identity storage

tenant-D1ルーティング

builtin:storage:tenant-d1 モードでは、tenant databaseを解決できない場合にテナント所有データを共有D1へ暗黙にfallbackすることは許可しません。Runtime source resolutionは以下を使います。

  • storage profile内の tenant-database-registry target
  • DB_ADMIN に保存されたregistry rows
  • 任意の署名済み TENANT_RUNTIME_REGISTRY KV snapshots
  • 1リクエスト内での繰り返しregistry readを避けるrequest-scoped cache

対応していないtenant-D1 routeでは、ストレージ境界をまたいでfallbackするのではなく、PIIを含まない失敗レスポンスを返します。これは意図的な挙動で、tenant profileやrouting bugによってPIIが誤ったplaneに流れることを防ぎます。

Durable Objectの状態管理とシャーディング

Durable Objectsは、プロトコル操作のhotで強整合な状態を所有します。現在の主なbindingは以下です。

  • SESSION_STORE と SESSION_CLIENT_STORE
  • AUTH_CODE_STORE
  • REFRESH_TOKEN_ROTATOR
  • CHALLENGE_STORE
  • RATE_LIMITER
  • PAR_REQUEST_STORE
  • DPOP_JTI_STORE
  • DEVICE_CODE_STORE
  • CIBA_REQUEST_STORE
  • TOKEN_REVOCATION_STORE
  • SAML_REQUEST_STORE と SAML_AGGREGATE_METADATA_STORE
  • FLOW_STATE_STORE
  • KEY_MANAGER

セットアップ設定では、高トラフィックなauth state向けに以下のシャード数を指定できます。

設定デフォルト
authCodeShards4
refreshTokenShards4
sessionShards4
challengeShards4

Durable Objectのhot stateとD1 cold persistenceはprofileで制御されます。たとえばshared-D1 profileではsessionやdevice/CIBAのcold persistenceを有効にできますが、tenant-D1やexternal-durable profileでは、より多くのtransient stateをdeployment D1から切り離します。

Location hintはセットアップで設定できますが、レイテンシー保証ではなく配置のガイダンスとして扱うべきです。

キャッシュ戦略

Authrimは、データベース読み取りを最小化するために3層キャッシュ戦略を使用します。

block-beta
    columns 1
    kv["KV / Runtime Snapshots
Config、cache、tenant registry"]
    do["Durable Objects
Hot protocol state"]
    d1["D1 / External SQL
Persistent planes"]
  • KV: 生成設定、cache、consent cache、tenant runtime registry snapshot向けの結果整合なグローバルストレージ。
  • Durable Objects: プロトコル操作の強整合なhot state。
  • D1 / 外部SQL: Runtime storage profileが選択するcontrol、identity、PII、audit、policyの永続plane。

tenant-D1 routingが関わる場合、cache scopeにはstorage profile ID、source generation、schema versionが含まれます。これにより、tenant storage migration後に別世代のtenant databaseのデータが再利用されることを防ぎます。

次のステップ