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でのアカウント無効化を別の操作として扱います。 この記事で扱うのはセッションです。トークンがいつ効かなくなるかは、 トークンのイントロスペクションと失効で扱っています。
この連携には、上流のIdP、Authrim、自社アプリが登場します。 真ん中にいる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万件という余裕を次の保存先を用意する目安にします。
使えるシャードの余裕が減ると、用意してある予備を割り当てます。複数のテナントで一つのシャードを使う共有型でも、一つのテナントだけが使う専有型でも、考え方は同じです。
共有テナントのみ
専有テナントのみ
共有・専有が混在
自動プロビジョニングを設定しておけば、登録数が増えるたびに担当者がデータベースを作る必要はありません。テーブルを用意し、新しい登録先につなぐ作業も繰り返さずに済みます。容量を増やすたびに、既存アカウントの引っ越しを計画する必要もありません。
担当者は、増設の進み具合や失敗の有無、利用量と費用が想定内かを見ます。権限不足やサービス側の上限で止まったときは、人が対応します。それ以外の保存先の準備は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 向けのオープンソース・アイデンティティプラットフォームを評価してみてください。主要なプロトコル機能は実装済みで、プロダクション向けの堅牢化を継続中です。