Cloudflare Workers 向けの、OpenID Certified™ オープンソースのアイデンティティ＆アクセスプラットフォーム。 認証・認可・フェデレーションをエッジファーストの構成で提供します。
Pre-1.0。 主要プロトコルは実装済み。 プロダクション向けの堅牢化と検証を継続中です
WebAuthn パスキーと6桁のメールコードで、パスワードに頼らないログインを提供。パスキー未登録のユーザーには、メールコードを代替手段として用意できます。
OpenID Connect・SAML 2.0 で、アプリや既存の認証基盤と連携。初回ログイン時のアカウント作成や、外部アカウントとの紐付けにも対応します。
ロール（RBAC）・属性（ABAC）・関係性（ReBAC）で、誰が何にアクセスできるかを制御。テナントごとのポリシーに基づき、API で権限を確認できます。
ユーザーの増加に合わせて Cloudflare D1 を自動拡張。必要容量を予測してデータベースを追加し、小さく始めて基盤を乗り換えずに成長できます。
プロダクトノート
個人情報の分離で、障害調査と削除を支える。
プロダクトノート
この設計は、規制対応から生まれたものではありません。「ログインできない」の調査をしていて、見なくていいものを見てしまうという、運用の現場で毎回起きていた居心地の悪さが出発点です。
IDの基盤を提供していると、こういう連絡が来ます。「特定のユーザーがログインできない」。 原因を調べるには、そのお客様が使っている環境に入り、該当アカウントを探すことになります。
このとき知りたいのは、たいてい次のようなことです。 アカウントはロックされているか。最後の認証試行はいつで、どこで落ちたか。 どの経路でログインしようとしたか。パスキーの登録は生きているか。
どれも、その人が誰であるかとは無関係です。 それなのに、アカウントを開いた瞬間に氏名が出ます。メールアドレスが出ます。 電話番号も、連携先のアカウント名も、同じ画面に並んでいます。 調査に必要なのは状態だけなのに、人格が一緒についてきます。
「見ないでください」という運用ルールは、
画面に表示されている限り機能しません。
しかもこれは、こちらに落ち度があって起きることではありません。 お客様から調査を依頼され、正規の手続きで入り、必要な作業をしている。 それでも見えてしまう。構造がそうなっているからです。
規則や研修で対処しようとすると、担当者の記憶力と良心に依存した仕組みになります。 そして依存している限り、いつか事故として表面化します。 Authrim が個人情報を別のデータベースに分けているのは、 まずこの一点を設計で解けないかと考えたからです。
IDの仕組みを作ると、扱うデータは自然に混ざります。 ユーザーの氏名やメールアドレス。どのアプリを使う権限があるか。今どの端末からログインしているか。 パスキーの登録情報。外部IDとの連携先。
これらは全部「ユーザーに関するデータ」なので、素直に作るとひとつのデータベースに同居します。 動作としては何も問題ありません。問題が出るのは、聞かれたときです。
「個人情報の所在を図示してください」「漏洩した場合の影響範囲は」「削除依頼への対応手順は」。 全部が同じ場所にあると、答えは毎回「ユーザーテーブル一式」になり、 範囲を絞った説明ができなくなります。
Authrim は、個人を特定できる情報だけを物理的に別のデータベースに置きます。 あとから分離したのではなく、リポジトリ層の構造からして別系統です。
分けておくと、まず冒頭の調査の話が解けます。 ロック状態も、認証の失敗記録も、端末の情報も、左側だけで足ります。 障害調査に必要な権限を、右側に触れないまま渡せる。 担当者が「見ないように気をつける」必要がなくなります。
同じ構造が、審査や監査の質問にもそのまま効きます。 「氏名やメールアドレスがどこにあるか」に即答でき、削除の手順も範囲で示せる。 先に運用の問題として解いた結果が、たまたま説明能力にもなったという順序です。
ここは誤解されると危険なので、はっきり書きます。 この分離は「個人データ／非個人データ」の法的な線引きではありません。
Core DB 側にも、IPアドレス、端末情報、セッション履歴、認証イベント、資格情報のメタデータ、 内部的な安定ユーザーIDなどが入ります。これらも状況によっては個人データに該当します。 単独では個人を特定しなくても、他の情報と組み合わせれば特定に至ることがあるためです。
Authrim が実際に分けているのは、直接的に個人を識別できるデータと、 運用上のアイデンティティデータです。 前者に触れずに後者だけで障害調査ができる、というのがこの設計の狙いであって、 後者が保護不要という意味ではありません。
したがって「個人データは PII DB にしかない」というのは誤りです。 正確には「氏名・メールアドレスなど直接識別できるデータを PII DB に隔離し、 障害調査の権限をそこに触れずに発行できる」という設計です。
「アカウントを削除してください」という依頼が来たとき、消すこと自体は簡単です。 難しいのはその後に来る二つの要求です。
ひとつは消したことの証明。いつ、誰が、なぜ消したのかを後から示せる必要があります。 もうひとつは消した人が再登録してこないこと。 退会直後の再登録を一定期間止めたい、という業務要件はよくあります。
ここで矛盾が起きます。どちらの要求も「消したはずの人を識別すること」を求めるのに、 識別できる情報を残していたら、そもそも消したことになりません。
実装のコメントには、設計判断がそのまま書かれています。 個人情報は保存しない。重複防止のための指紋だけを持つ。保持期限を過ぎたら自動的に消える。 誰が・いつ・なぜ削除したかは記録する。
技術者向けに一点補足します。メールアドレスはエントロピーが低いため、 単純なハッシュで指紋化しただけでは、辞書攻撃で元の値を突き止められます。 「復元できない」は無条件には成立しません。
Authrim の実装は HMAC-SHA256 に秘密鍵を用いたブラインドインデックスで、 鍵世代の番号を持つため鍵の更新にも対応しています。 鍵を知らなければ、指紋の総当たりはできません。
逆に言えば、鍵の隔離がこの保証の前提条件です。 鍵が指紋と同じ場所に置かれていれば保証は失われます。
「ログインできない」という問い合わせに戻ります。担当者が知りたいのは、どこで認証が止まったかです。氏名や電話番号まで開く必要はありません。
Authrimでは、直接識別できる情報の保存先を分け、調査に必要な情報へアクセスする権限を、その保存先に触れずに渡せるようにしています。個人情報が必要な調査では、別途その権限を持つ担当者が扱います。
暗号化やアクセス制御で守り、監査ログで扱った事実を確かめる。そのうえで、普段の調査では必要のない個人情報を開かずに仕事を終えられる。保存先を分けたのは、その状態を日々の運用の出発点にするためです。
実装 完了（保存とアクセス境界の分離が動作）
検証 自動テストで継続的に確認
運用成熟度 本番向けの追い込み中。Authrim 全体が pre-1.0 です。
なお、この設計は削除依頼への対応をやりやすくするものであって、 それ自体が法令順守を意味するわけではありません。 実際の適合性は、運用手順や契約を含めた組織側の判断になります。
OP・RPのログアウト認定が確かめること。
プロダクトノート
ユーザーがログインするのは一度きりです。でも、その裏で作られる「鍵」は一本ではありません。ログアウトするときは、どの鍵を回収し、どこまでログイン状態を終了するのかを考える必要があります。
自社サービスに「Googleでログイン」を付けたとします。ユーザーの体感は「ボタンを一回押した」だけです。 ところが内部では、ログインの通り道にあるシステムがそれぞれ自分の鍵（セッション）を発行して保管します。
Google が一本、Authrim が一本、自社アプリが一本。合計で三本です。 セッションが残った場所では、操作を続けられたり、パスワードを再入力せずに入り直せたりすることがあります。
ログアウトとは、画面に「ログアウトしました」と出すことではなく、
終了させたい範囲を決め、その範囲のセッションを終了させることです。
ここで「鍵」と呼んでいるのはセッションです。 アクセストークンやリフレッシュトークンは別の仕組みで、 セッションを終了しても、発行ずみのトークンが自動的に失効するとは限りません。 トークンを止めるには失効（revocation）という別の操作が必要です。
OIDC の用語で言えば、セッションのログアウト・トークンの失効・上流IdPでのアカウント無効化は それぞれ別の操作です。この記事が扱うのはセッションの側だけで、 トークンがいつ効かなくなるかは トークンのイントロスペクションと失効で扱っています。
ここで押さえておきたいのが、Authrim のポジションです。 この連携では、上流のIdP、Authrim、自社アプリがそれぞれ役割を持ちます。
上流IdPは、自社サービスから見て「ログインさせる側」。 自社アプリは「ログインを頼む側」。 ところが Authrim は、上を向くか下を向くかで立場が入れ替わります。
問題はここからです。ログインは上から下へ自然に流れますが、ログアウトは誰かが能動的に伝えないと伝わりません。
上流IdPのセッションを終了しても、Authrimや自社アプリのセッションまで自動的に消えるとは限りません。 下流にも終了を伝え、受信した側が対象セッションを終了する処理が必要です。次の図は、必要な通知方式と設定が揃った場合の連鎖を示しています。
「鍵が残る」と言われてもピンと来ないと思うので、実際に問い合わせや監査で表面化する形に翻訳します。
| 場面 | 連鎖がないと起きること |
|---|---|
| 退職・アカウント停止 | 人事側で権限を止めたのに、当人のPCではアプリが開いたままで、翌朝まで社内データが見えていた。 |
| 共有端末 | 店舗・病院・コールセンターで、前の担当者がログアウトしたはずなのに、別タブを開いたら前の人の画面が出た。 |
| 端末の紛失・盗難 | 「全デバイスからログアウト」を押したのに、実際には手元の端末のセッションしか切れていなかった。 |
| インシデント対応 | 不正アクセスを検知して該当ユーザーを止めたが、攻撃者のセッションだけは有効期限まで生き続けた。 |
| 監査・審査 | 「ログアウトが全システムに伝わることを示してください」と言われ、示す材料がない。 |
どれも「ログアウト機能がない」わけではありません。ボタンはあるし、押せば画面も切り替わります。 効く範囲が思っているより狭い、というのがこの問題の厄介なところです。
では、どうやって下流に伝えるのか。方法は大きく二つあります。 そして今、片方が壊れつつあります。
Authrim が対応しているのは、この下の方式を受け取る側の能力です。 受信側の処理と、下流アプリへの送信側の処理を、それぞれ確かめる必要があります。
Authrimは、上流のIdPに対してはログインを頼む側（RP）、アプリに対してはログインを提供する側（OP）になります。ログアウトを中継するためにも、それぞれの立場で仕様に沿って動く必要があります。
この二つの役割を確認する材料が、OP・RPそれぞれのログアウトプロファイル認定です。Authrimは、OpenID Foundationの公式適合性テストを使ったセルフ認定手続きを経て、両側のログアウトプロファイル認定を取得しています。
認定が示すのは、対象バージョンの実装が、申請したプロファイルの適合性テストを通過したことです。お客様の接続先やネットワークを含めて、すべてのセッションが即座に終了することを保証するものではありません。
実際に連鎖をつなぐには、上流IdPと各アプリが必要な方式に対応し、通知先と対象セッションの対応付けが設定されている必要があります。上流でのアカウント停止が必ずログアウト通知を発生させるとも限りません。通知が届かなかった場合の再送や失敗の確認を含め、利用する構成で確かめます。
認定の対象とバージョンは、OpenID Foundationの Certified OpenID Relying Parties & Logout Profiles と 認定制度の説明 から確認できます。
ログアウトしたあと、どこにログイン状態が残るのか。
共有端末を次の人へ渡すときも、退職者のアクセスを止めるときも、確認したいのはこの範囲です。Authrimは通知を受け取る側と配る側を担い、上流IdPとアプリの間でセッション終了をつなぎます。認定をその実装の確認材料にしながら、接続先も含めて意図した範囲に届くかを確かめていきます。
パスワードを保存せず、LDAP・ADと連携する。
プロダクトノート
社内のActive Directoryにパスワードがある。この前提は動かせません。ではモダンなログインをどう載せるか。パスワードハッシュを複製せず、社内への新しい受け口も公開せずにつなぐ。そのための接続がAuthrim Relayです。
従業員のアカウントは Active Directory にあります。パスワードポリシーも、失効も、 退職時の停止も、そこで運用されています。何年も回ってきた仕組みです。
そこにパスキーを入れたい。多要素を整理したい。SaaSへのSSOを増やしたい。 やりたいことは明確なのに、最初の一歩で必ず同じ問いにぶつかります。 「パスワードの検証を、どこでやるのか」
パスワードハッシュをクラウドに同期する構成も、社内のディレクトリへ検証を頼む構成もあります。選ぶときに確認したいのは、認証情報をどこに置くか、どちらから接続するか、誰がその経路を運用するかです。
WordWardenでは、LDAP/ADに検証を任せたまま、接続経路を選べます。特に社内への新しい受け口を公開したくない組織のために、外向き接続で使うAuthrim Relayを用意しています。
Authrim WordWarden は、Authrim 用のディレクトリコネクタです。 社内のLDAP/ADのすぐ隣に置く小さなサービスで、やることは一つに絞られています。 渡されたユーザー名とパスワードをディレクトリに問い合わせ、結果だけを返します。
ログイン画面、セッション、パスキー、メールコード、フェデレーション出力、監査の相関、 アイデンティティのマッピングは Authrim 側が持ちます。 WordWarden は検証だけを、ディレクトリの隣で行います。
接続の向きによって、必要なネットワーク設定と運用するものが変わります。
WordWarden は三つの接続方式を持っています。違いは「社内に受け口を公開する必要があるか」です。
新しく導入し、社内への受信を増やしたくないなら、まずRelayを検討します。すでに使っている公開基盤やトンネルがある場合には、それを使う利点もあります。以下は導入実績ではなく、構成を選ぶ場面の例です。
たとえば、ADを本社内で運用し、外部公開サーバーを増やすには別部門の審査が必要な企業。あるいは、学内LDAPに対する外部からの接続を認めていない大学です。WordWardenからAuthrimへ接続するので、社内・学内向けの受信ポートを新たに公開せずに始められます。
公開エンドポイントや別のトンネル用プロセスを増やさずに済むのが利点です。外向きのWebSocket通信を許可できることが前提で、WordWardenの稼働と接続状態は監視します。外部通信自体が禁止されているネットワークには使えません。
社内ツールをCloudflare Tunnelで公開していて、cloudflaredの更新や経路設定を担当するチームがある組織なら、その運用に載せられます。新しい受信ポートを開けずに、既存のトンネル運用の手順を使える点が利点です。
Authrimからコネクタへ要求が届くホスト名と経路を設定し、トンネルの稼働も管理します。社内ホストへの直接の受信は不要ですが、Cloudflare上の経路を介して要求を受ける構成です。
たとえば、企業や大学・研究機関の情報基盤部門がDMZとリバースプロキシを運用し、外部連携をそこに集約している場合です。Authrimから到達できるHTTPSの受け口を用意し、既存の証明書管理、アクセスログ、監視の手順で扱えます。
別のトンネルやRelayの接続を維持する必要がないのが利点です。その代わり、受信経路の許可と公開エンドポイントの保護・保守を引き受けます。公開するのはコネクタのHTTPS経路で、LDAP/ADのポートを直接インターネットへ開ける構成ではありません。
どの方式でも、LDAP/ADに到達できる場所でWordWardenを運用する必要があります。学術機関だから方式が決まるわけではなく、公開基盤の有無とネットワークの方針で選びます。
Relay モードでは、WordWarden が社内から Authrim へWebSocket で接続します。 WebSocketは、一度つないだ通信経路を保ち、両側からメッセージをやり取りできる仕組みです。
WordWardenは、その接続を保って待ちます。ログインが発生すると、Authrimは同じ経路で 「このユーザーを確認してください」と依頼し、WordWardenが社内のディレクトリで確認した結果を返します。
社内からかけた電話をつないだまま、相手からの話も聞けるようなものです。 依頼のたびに、外から社内へ接続し直す必要はありません。
実務上の意味はシンプルです。ディレクトリ側のネットワークは、URLを一つも公開しません。 新しい公開エンドポイント用のホスト名・証明書・WAFを管理する負担を減らせます。 外向き接続の許可に加え、WordWardenの保守と接続の監視は引き続き必要です。
違いは、最初の接続をどちらから始めるかです。Direct HTTPSでは、Authrimから接続できる受け口を組織側に用意します。Relayでは、組織内のWordWardenがAuthrimのRelayへ暗号化されたWebSocket接続（wss）を張ります。
一般的なステートフルファイアウォールやNATでは、内側から始めた接続の通信を追跡して、戻ってくるデータを通します。そのため、社内のWordWardenに対して外部から新規接続を受け付けるポート公開やポート転送を設けずに、検証要求を受け取れます。
通信にポートを使わない、という意味ではありません。通常のwssでは接続先のTCP 443番ポートを使います。組織のファイアウォールやプロキシで、Relayへの外向き通信とWebSocketの継続接続が許可されている必要があります。接続が切れている間はその経路で要求を受け取れないため、接続状態の監視も必要です。
外部から新しく接続できる受け口を減らしても、確立した接続には検証要求が届きます。相手の認証や、受け取った要求の検証は引き続き必要です。
接続を外向きにしても、接続相手の認証は必要です。Relayでは、接続先とコネクタの確認を組み合わせます。
WordWardenは、短命なチャレンジに対するHMAC応答で認証します。チャレンジIDとノンスを含む文字列に署名し、接続先URLのテナントIDとコネクタIDが自分の設定に一致するかも確認します。
HMACは三つの接続方式すべてで必須です。Relayが減らすのは内向きの露出であり、コネクタ認証やシークレット管理を省くものではありません。
ここは曖昧にすると危険なので、はっきりさせておきます。 「パスワードが社外に出ない」わけではありません。
ログイン画面にパスワードを入力する以上、それは Authrim を通過します。 正確な主張は「AuthrimとWordWardenには保存しない」であって「社外に出ない」ではありません。
検証が成功したとき Authrim に返るのは、判定結果と、要求した属性のうち コネクタ側の許可リストに載っているものだけです。 要求した側が取れる範囲を決めるのではなく、ディレクトリ側が渡す範囲を決めます。
この向きは重要です。Authrim 側の設定変更だけで、社内から引き出せる属性を増やすことはできません。
この連携は、移行期間のための橋です。
LDAP/AD をパスワードの正本のまま据え置き、そのアカウントでログインできる状態を保ちながら、 裏でパスキーの登録を進めていく。メールコードは復旧経路として残す。 ユーザーから見れば「今までどおり入れる」まま、認証方式だけが入れ替わっていきます。
ドキュメントは移行時の禁止事項も明示しています。 LDAP/AD のパスワードハッシュを Authrim に書き出さないこと。 これをやると、橋を架けるつもりが認証情報の複製になります。
公開ベータ準備中。最初の公開ベータ目標は v0.1.0-beta.1 です。
想定用途はパイロット。LDAPの隣に小さなサービスを運用でき、 ディレクトリ・ネットワーク・TLS・シークレット管理の境界を理解している組織向けです。 マネージドなディレクトリサービスではありません。
Authrim 0.3.2 以降（Directory Authentication と Relay を有効化）が必要です。 現ベータでは設定変更にプロセス再起動が必要です。
「認証情報を出すか、境界を開けるか」は
二択ではありません。
検証をディレクトリの隣で行い、接続を外向きだけにする。 この二つを同時に満たすと、パスワードハッシュを複製することも、 社内に受け口を公開することもなく、モダンなログインを載せられます。
そして載せた先にあるのは、パスワードの継続利用ではなくパスキーへの移行です。 ディレクトリ連携は、その移行をユーザーを止めずに進めるための足場として置かれています。
既存アカウントを動かさず、D1を増やす。
プロダクトノート
ユーザーが増えてきた。うれしい反面、認証データをいつまで今のデータベースに置けるのかが気になり始める。移行先を選び、データを分け、切り替えの手順を組む。その仕事を、サービスが忙しくなってから抱えたくはありません。Authrimは、新しいアカウントを受け入れるデータベースを、必要になる前に用意します。
Authrimが使うCloudflare D1には、データベース1つあたりの容量に上限があります。無料プランでは500MB、有料プランでは10GB。ユーザーや保存する情報が増えれば、どこかで次の置き場所が必要になります。
そのときに全員分のデータを移し替えずに済むよう、Authrimは最初から、アカウントを複数のデータベースへ振り分けられる構成にしています。分割した保存先の単位を、ここでは「シャード」と呼びます。
すでに登録されているアカウントは元の場所に置いたまま、新しく登録されるアカウントの保存先を増やす。これが、アカウント用データベースを拡張するときの基本です。
OAuthクライアントやポリシーなどのテナント設定、ユーザーのアカウントと個人情報、メールアドレスなどから保存先を探すための索引。Authrimでは、これらを別々に保存しています。
ユーザーが増えたからといって、すべてのデータベースを一緒に増やす必要はありません。アカウント用と検索用では、必要な件数も増加のペースも違います。それぞれの状況を見て、容量を追加します。
新しいアカウントの保存先は、そのテナントが使えるシャードの中から選びます。健康に動作していて、目標件数に対する割当件数の割合が低いものを優先します。
判断の基準になるのは、ディスクの使用率ではなく、設定した目標アカウント数に対して、あと何件を受け入れられるかです。たとえば目標を10万件とした場合、残り2万件という余裕を、次の保存先を準備する目安にします。
利用できるシャードの余裕が少なくなると、用意してある予備を割り当てます。複数のテナントが同じシャードを使う共有型でも、1つのテナントだけが使う専有型でも、この考え方は変わりません。
共有テナントのみ
専有テナントのみ
共有・専有が混在
自動プロビジョニングの設定を済ませれば、登録数が増えるたびに担当者がデータベースを作り、テーブルを用意し、新しい登録先へつなぐ作業を繰り返す必要はありません。既存アカウントの引っ越し計画も、容量を追加するたびには要りません。
担当者が見るのは、増設が進んでいるか、失敗していないか、利用量と費用が想定の範囲かです。権限不足やサービス側の上限で止まれば対応する。この役割分担を前提に、Authrimが次の保存先を用意します。
残り2万件あっても、1日に100件増えるサービスと、1時間に1万件増えるサービスでは、用意を急ぐ度合いが違います。
そこでAuthrimは、現在の割当件数に加えて、直近の登録ペースから今後必要になる容量を見積もります。アカウント用も検索用も予測の対象です。定期処理は1分おきに動き、アカウントの割当後にも予測を更新します。
必要な量を計算するときは、すでに作成中のシャードも数に入れます。複数の処理が同じ容量不足に気づいても、そのたびに余分なデータベースを作らないためです。
予備だけでは足りないときは、Cloudflareの管理APIを使ってD1を作成します。テーブルを用意し、Workerから参照できるよう設定し、新しい保存先の情報を配布する。読み書きを確認できたものから、割当先として使い始めます。
自動で進めるには、自動プロビジョニングを有効にし、D1用とWorkers用のAPIトークンをそれぞれ設定する必要があります。自動実行できない場合は、運用者がセットアップツールで処理を進める形になります。
作成の途中経過は保存されます。一時的な通信障害なら、その状態をもとに再試行できます。権限不足やリソース上限など、人の対応が必要な理由で止まった場合は、原因を解消してから再開します。
準備が追いつかず登録枠がなくなった場合には、新規登録の再試行が必要になることもあります。先回りして用意するのは、そうした待ち時間をできるだけ減らすためです。
容量の追加と、既存データの移動は別の操作です。たとえば、共有シャードで始めたテナントを専有シャードに移す場合。新しい登録先を増やすだけでは済まず、すでにあるデータも移す必要があります。
この移行を始めるかどうかは、運用者が判断します。承認を受けた後の同期、検証、切り替えは、Authrimが進めます。
現在、対応している配置変更は共有から専有への移行です。専有から共有へ戻す移行や、既存アカウントを自動で均等に配置し直す機能はありません。
使い終えたシャードの削除にも、人の承認が必要です。使う容量が増えたからといって、既存データの移動や削除まで自動で始まることはありません。
2026年7月のテストデータによる計測では、20万アカウントを保存した時点で、Coreが約208MB、PIIが約238MB、Lookupが約426MBでした。それぞれ、有料プランの1データベースあたり10GBという上限に対して5%未満です。保存する属性や索引によって、実際の使用量は変わります。
目標アカウント数の初期値は、1シャードあたり10万件です。物理的に入るだけ詰め込むのではなく、次を用意する余裕を残しています。
Authrimはpre-1.0で、この仕組みの長期間・大規模な本番運用での実績は、これから積み上げていく段階です。20万件の保存容量を測った結果と、数百万人が日々使う環境での運用実績は、分けて見ています。
小さなサービスのうちから、大規模な構成を用意しておく必要はありません。少ないシャードで始めて、登録の増え方に合わせて保存先を足していく。そのための準備と手順を、Authrimの中に組み込んでいます。
ユーザーが増えてきたときに、まずデータベースの引っ越しを考える。その仕事を減らして、サービスを育てるほうに時間を使えるようにしたいと考えています。
容量の計測：2026年7月30日、テスト環境の20万アカウント。MBは10進表記。D1の容量上限はCloudflareの公式仕様。
K6 Cloud による試験は代表的な OIDC ワークロードを対象としています。実際の処理能力はワークロードの形状、Cloudflare プランの上限、ストレージ、シャーディングに依存します。
テストレポート →Authrim にはユーザー単位のベンダー料金はありません。インフラコストはリクエスト数・CPU 時間・ストレージ・ログに依存します。これは本番見積もりではなく、おおよその Cloudflare コストの目安です。
Cloudflare Workers の料金をベースに、観測された Authrim の利用パターンから KV・Durable Objects・D1 分を係数として加味しています。
注 — インフラのみ。コンプライアンス、監視、サポート、運用、セキュリティレビュー、外部データベース、大規模な R2/アーカイブ利用は含みません。実際のコストはデプロイ構成により異なります。
TypeScript ファーストの API、JavaScript SDK、エッジ・アイデンティティの評価・開発のためのセットアップワークフロー。
SAML・SCIM・監査ログ・テナント境界、堅牢化を進行中のストレージ／ログ制御を備えた、セルフホストの管理。
Authrim のユーザー単価ゼロで Cloudflare 上に始め、計測されたリクエスト・CPU・ストレージ・ログの挙動に応じてスケール。
OpenID 認定
Authrim v0.4.0
7カテゴリ・計28プロファイル
カテゴリ名から公式認定一覧へ。
Basic OP · Implicit OP · Hybrid OP · Config OP · Dynamic OP · Form Post OP · 3rd Party-Init OP
RP-Initiated OP · Session OP · Front-Channel OP · Back-Channel OP
Basic RP · Config RP · Dynamic RP · Form Post RP
RP-Initiated RP · Back-Channel RP
Security Profile: private key + DPoP · OpenID Connect · Message Signing: JAR · Message Signing: JARM · Client Credentials: private key + DPoP
Security Profile: private key + DPoP · OpenID Connect · Message Signing: JAR · Message Signing: JARM
Poll: Private Key · Ping: Private Key
Cloudflare Workers 向けのオープンソース・アイデンティティプラットフォームを評価してみてください。主要なプロトコル機能は実装済みで、プロダクション向けの堅牢化を継続中です。