Thomas Aidan CurranがOryをidentityの部品表へ変えた転換

Oryは、顧客・business user・machine・AI agentのidentityとaccess controlを、open-source componentsとmanaged Ory Networkで提供するIAM platformである。出典

Thomas Aidan Curranは、Oryについて「Ory simplifies zero trust security by putting ID management, authorization, and access control into one cloud system that is globally distributed and runs using multiple clouds」と語った。出典

この言葉は、Oryが単なるlogin widgetではなく、identityの複数の責務を組み合わせる基盤を目指したことを示す。

オープンソースを境界ごとに分ける

OryはKratos、Hydra、Keto、Oathkeeperを別々のbuilding blocksとして公開した。

user identity、OAuth2/OIDC、permissions、request-level access controlを分けることで、チームは必要な責務だけを選べる。出典

クラウドへ移す転機

self-hostedの自由度は強みだが、identity基盤の運用は監視、upgrade、security responseまで含む。

OryはOry Networkを、open-source serversと互換性を持つmanaged platformとして広げた。出典

2021年にはInsight Partners主導で$22MのSeries Aを調達した。

資金の意味は機能数の追加だけではなく、OSSで獲得した開発者の本番運用をクラウドへ移すための組織と信頼の構築にある。出典

AI agentsまで広がるidentity

Oryの現在の提案は、顧客、business users、machines、AI agentsを同じIAMの問題として扱う。

人間向けのloginから、requestごとのpermissionとtokenへ焦点を広げた。出典

この道のりから見えるのは、identityを一つの画面として売るのではなく、変化する主体と境界を部品化する戦略だ。

Oryの勝負は、OSSの採用をOry Networkの運用価値へどこまで連続させられるかにかかっている。

OryのPMFは、ログイン画面だけでなく認証・OAuth2・権限・API gatewayまでを自社で安全に組み合わせたい開発チームにある。

Kratos、Hydra、Keto、Oathkeeperを分解可能なbuilding blocksとして選べるため、既製CIAMに全面依存せず、self-hostとmanaged cloudを使い分けられる。出典

一方で自由度は設計責任も増やす。

Ory NetworkのaDAU課金やEnterprise機能は、規模と要件が明確なチームほど価値が出る構造だと考えられる。出典

moatは、identityの各境界をOSSとして実装し、Kratos・Hydra・Keto・Oathkeeperの相互運用を積み上げる技術エコシステムにある。出典

ただしOSS単体は複製できるため、防御力は運用知識、managed platform、security実績へ移る。

ネットワーク効果は弱い。

ユーザー同士が直接つながるプロダクトではなく、導入企業のidentityデータと権限モデルが利用継続を支える。出典

代わりに、GitHub・Docker・docsを通じた開発者コミュニティと、標準プロトコルへの適合が採用を広げる間接効果を持つ。

主な対象は、顧客向けアプリ、B2B SaaS、machine-to-machine API、AI agentsに認証・認可を組み込みたい開発チームである。出典

単純なsocial loginだけを追加したい小規模プロジェクトより、tenant、permissions、OAuth2、data residencyを設計する組織に向く。

成功要因は、identityを一枚岩のSaaSではなく、用途別のOSS componentsとして切り出したことだ。

Kratosはuser identities、HydraはOAuth2/OIDC、Ketoはpermissions、Oathkeeperはaccess controlを担当し、必要な境界だけ採用できる。出典

Apache 2.0のself-hosted選択肢とOry Networkのmanaged運用を併存させたことも、導入初期と本番運用の摩擦を下げる。

課題は、複数componentsの組み合わせがidentity専門家のいないチームには複雑になりやすいことだ。

認証・認可・gatewayの責務を誤ると、実装速度よりセキュリティレビューの負債が先に膨らむ。出典

また、self-hostedは運用責任を顧客側に残す。

Ory Networkの価格・aDAUモデルやEnterprise Licenseへの移行条件は、トラフィックと規制要件を事前に見積もれない組織には不確実性となる。出典

成長戦略は、OSS componentsで開発者に入ってもらい、Ory Networkのmanaged運用、監視、multi-tenancy、SLAへ拡張する流れだ。出典

self-hostを残すことでvendor lock-inへの警戒を和らげる一方、クラウドの価値は運用負担とenterprise要件に絞る。

この境界設計が、OSSの普及と商用化を両立させる。

主要チャネル: github, community, content, seo

identity基盤は、ログインUIではなく責務の境界から設計すると拡張しやすい。

Oryはuser identity、token、permission、request policyを別componentに分け、プロトコルとAPIで接続した。出典

OSSとmanaged serviceを併置するなら、同じcoreを使いながら、運用の痛い部分だけを有料化する線引きが重要になる。

日本では、SaaSの顧客企業ごとのtenant管理、金融・医療のdata residency、社内外のmachine identityが同時に難しくなっている。

Oryの分割型IAMは、巨大な認証製品を一括導入する前の選択肢になり得る。出典

ただし、日本企業向けにはSIer・監査・導入支援が重要で、OSSの自由度を運用テンプレートへ翻訳するパートナー戦略が必要だと考える。