Ory導入事例：ティアフォー様がID基盤をOryに移行した理由と移行設計

本記事は、Ory公式ブログに掲載されたティアフォー様（TIER IV）のOry導入事例「How and why TIER IV replaced IdentityServer with Ory」の内容を、日本唯一のOry公式パートナーであるスタジオメッシュがOry社の許可を得て日本語で紹介するものです。

ティアフォー様のOry導入事例の概要

ティアフォー様は、自動運転システムの開発で知られる企業で、運行管理システムや遠隔監視・操作システム、自動運転用の地図エディタなど多数のサービスを運営しており、そのすべてのサービスの土台となるID基盤を、PythonのDjangoで構築した自社実装からOryの各製品へ移行しました。

項目	内容
移行前	Django（Python）で構築した自社実装のID基盤（アカウント管理とIDフェデレーション）
移行後	Ory Kratos（ID管理・認証）、Ory Hydra（OpenID Provider）、Ory Oathkeeper（アクセス制御プロキシ）＋Go製の自社実装
比較した製品	AWS Cognito、Keycloak
移行期間	約3か月
結果	大きな問題なく移行を完了

ID基盤そのものは小さなサービスですが、停止するとすべてのサービスの可用性に大きく影響する重要な部品でした。なお、認可は別のサービスが担っており、今回の移行対象は認証とアカウント管理に限られています。

自社実装のID基盤から移行した理由

移行前のID基盤は、構築から年数が経っていたわけではありません。移行を決めた理由は、OpenID Providerとして使っていたライブラリの保守が止まっていたことにあります。ティアフォー様はそのライブラリをフォークして自社で修正しながら運用していましたが、メモリリークやリクエストの処理が止まる問題を抱えていました。

これらの問題は運用でカバーできていたものの、今後のトラフィック増加と信頼性要件の高まりを考えると、いずれスケーラビリティの限界に達することが見えていました。そこで、ユーザー数が少なくデータを移行しやすい時期のうちに、ID基盤を置き換える判断をしました。

既存データの移行で確認した3つの要件

ティアフォー様は、AWSを利用していることからCognitoのようなマネージドサービスを第一候補としつつ、対抗としてユーザー数に応じた課金がなくオープンソースに基づくものを条件に選定を進めました。ゼロからの自社開発は最後の手段という位置づけです。しかし、既存データを移行するための要件が選択肢を大きく絞り込むことになりました。ティアフォー様が検討した要件は次の3つです。

検討ポイント	判断	理由
自社システム内の既存ユーザーの識別子を変更できるか	できない	自社マイクロサービス間でIDが保存されており、すべてを一貫して置き換えるのは困難。現在の識別子を維持する必要がある
各システムが保持しているクライアントIDとシークレットを変更できるか	できる	旧シークレットを移行できれば理想だが、許容可能
移行に伴い、ユーザーにパスワードの再設定を強制できるか	できない	UXが悪いうえ、過去にメールアドレスの到達確認をしていなかった時期があり、リセットできないユーザーが発生する。

1つ目の要件への対応は、次の図のとおりです。新しいID基盤の内部ではIdentity Server（Ory Kratos）がUUID形式のIDを発行しますが、利用者や他のサービスとの間に自社実装を挟み、従来どおりのID（図ではID: 1）に変換しています。

ティアフォー様のID基盤のリプレース前後の構成図。リプレース前はDjangoが連番のIDをそのまま返していたが、リプレース後はIdentity ServerがUUID形式のIDを発行し、自社実装が従来のIDへ変換して利用者に返す

出典：How and why TIER IV replaced IdentityServer with Ory（Ory公式ブログ）

3つ目の要件であるPBKDF2でハッシュ化された既存パスワードをそのまま取り込めることが、Oryを採用する決め手になりました。

Ory Kratos・Hydra・Oathkeeperを組み合わせた新しい構成

ティアフォー様は新しいID基盤に、Oryの3製品と自社実装を組み合わせる構成を採用しました。各コンポーネントの役割は次のとおりです。

コンポーネント	役割
Ory Kratos	ログイン・ログアウト、ユーザー登録、プロフィール管理、アカウント回復、メールアドレス確認、多要素認証（MFA）
Ory Hydra	OpenID Connect認定のOpenID Provider
Ory Oathkeeper	アクセス制御を担うプロキシ。セッション情報を後段のサービスへ伝え、アクセストークンのスコープを検証する。KratosとHydraの管理APIの保護にも利用
自社実装（Go）	Kratosの各機能の画面、Kratosへ送信する前の追加検証、KratosとHydraの連携、既存のIDとの対応付け

Oathkeeperで管理APIを保護する部分について、ティアフォー様は管理API用にOAuth 2.0クライアントを発行し、スコープによる認可だけを行う形にとどめています。ユーザー単位の細かな認可が必要になった場合は、Ory KetoやOpen Policy Agentを組み合わせる想定です。

Kratosの採用にあたっては、PBKDF2ハッシュを取り込めるかどうかが判断の分かれ目でした。この機能をKratosに実装する変更をOryのリポジトリに提案し、採用されています。オープンソースであるOryでは、必要な機能をユーザー自身が実装して本体に反映できることを示す例です。

Keycloakではなく、Oryを選んだ理由

オープンソースの認証基盤としてはKeycloakのほうが知名度が高いものの、ティアフォー様は次の3つの理由からOryを選んでいます。

マイクロサービス構成： Oryは機能ごとに独立したサービスとして提供されるため、既存のデータや機能との互換性を保ちながら移行しやすい
Go言語への習熟： 社内でGoに慣れており、問題や疑問が生じたときにソースコードを直接調べられる
Ory Hydraへの貢献経験： 以前からHydraを利用し、開発にも貢献していたため、問題が起きても自ら修正して解決できる

移行を3か月で終えられた成功要因

ティアフォー様は、ID基盤のOryへの移行を大きな問題なく約3か月で完了しました。原文では、成功要因として次の2点を挙げています。

移行前に不要な機能を削った： 事業部門・法務部門と協力して不要な機能を洗い出し、利用者へ提供終了のスケジュールを通知しました。この調整には時間がかかったものの、移行範囲を最小化できたことで移行自体は円滑に進みました。
Oryがオープンソースである： 疑問がある場合には自分でソースコードを調査することができ、今後ID基盤に機能を追加したい場合も、自社で拡張できます。

スタジオメッシュからの補足

パスワードハッシュの移行可否は製品選定を左右する

認証基盤の移行では「既存のパスワードハッシュを取り込めるか」が製品選定を左右します。取り込めない場合は、全ユーザーにパスワードの再設定を求めるか、ログインのたびに旧システムで認証して新システムへ移す順次移行方式を採用する必要があります。Cognitoの場合は順次移行が可能ですが、旧システムを移行完了まで動かし続ける必要があるため、保守およびユーザー向けの周知の負担が大きくなります。

Ory Kratosは、bcrypt・Argon2・PBKDF2など複数の方式のハッシュを取り込めます。取り込んだハッシュは、ユーザーの次回ログイン時に推奨アルゴリズムへ自動で更新されるため、利用者に負担をかけずにハッシュの強度も引き上げられます。

KeycloakとOryの違い

KeycloakはJavaで実装され、管理画面やログイン画面を含む多くの機能を1つのサーバーで提供します。一方のOryは、モジュール構造で、Kratos・Hydra・Ketoなどを必要な分だけ組み合わせます。そのため、ティアフォー様のように「既存の仕組みに合わせて一部を自社実装で補いたい」場合や、画面のUXを自社で作り込みたい場合にはOryが適しています。

2026年時点で導入を検討する場合の確認点

原文の公開は2022年で、OryのOSS各製品はその後もバージョンアップを重ねています。現在Oryの導入を検討する場合は、次の2点を合わせて確認することをおすすめします。

運用形態の選択肢が増えている： ティアフォー様はOSSをセルフホストしていますが、現在はOryが運用するクラウド版のOry Networkや、セルフホスト向けの商用ライセンスであるOry Enterprise Licenseも選べます。提供形態の違いは「Oryとは？ChatGPTを支えるOSS認証基盤を公式パートナーが解説」で解説しています
自社実装の範囲を決める： ティアフォー様の構成では、画面・追加検証・KratosとHydraの連携・ID変換を自社実装で補っています。これらが負担になる場合にはスタジオメッシュのサービスを利用いただくことも可能です。