どうもみなさんこんにちは。バクラク事業部 Platform Engineering 部でID基盤などを管理するチームに所属してあれこれやっている @convto といいます。
先日イベントでバクラクの認証基盤について発表したのですが、そこで Ory Hydra を利用した OAuth2.0 認可サーバーの提供について軽く触れました。
そこでは詳細には深入りしなかったのですが、個人的には OAuth2.0 認可サーバーの構築にあたって Ory Hydra はバランスのよい選択肢だと思っており、実例として今回はバクラク事業部での構成例などをご紹介させて頂きます！
それではやっていくぞー
Ory Hydra とは
Ory 社が開発している OpenID Certified な OAuth2.0 Server です。
また、Apache 2.0 ライセンスで OSS で開発されています。
最近だと OpenAI での採用事例が話題になっていましたね！
Ory Hydra の面白いところは、それ自体がIdPとしての機能を持たないところです。以下 READMEを引用します。
Ory Hydra is not an identity provider (user sign up, user login, password reset flow), but connects to your existing identity provider through a login and consent app. Implementing the login and consent app in a different language is easy, and exemplary consent apps (Node) and SDKs for common languages are provided.
つまり Ory Hydra は標準仕様に準拠した OAuth2.0 認可サーバーを提供しつつ、認証と同意(consent)は別のアプリケーションに任せることができます。
これにより、すでにID管理の主体が存在するシステムなどにおいて、ID管理の主体を変更することなく標準仕様に準拠した機能を提供できます。
冒頭で「Ory Hydra はバランスのよい選択肢だと思っている」と触れた理由がここで、既存の認証システムを活かしながら、連携部分を実装するだけで OpenID Certified な実装を提供できます。
たとえば、既存システムですでに認証やアカウント管理をしているとき、業務領域に応じてさまざまな判定や処理がされていることがあると思います。
このとき Ory Hydra を利用すれば関連処理に大きく手を入れずに、標準仕様に準拠した機能提供ができます。
かつ、標準仕様なので 1st party として OAuth2.0 認可サーバーを利用するケースなどでも、将来の差し替えや移行などが行いやすくなります。
プロダクトへの Ory Hydra の組み込み
基本的にはアカウント管理や認証/同意などについて既存のアプリケーションの処理を利用し、クライアント管理など OAuth2.0 認可サーバーとして機能するために必要な要素を Ory Hydra が担当しています。
概観
hydra 自身は公式でコンテナイメージが提供されているので、それにいくつか設定を追加したイメージを作成しセルフホストする形で運用しています。
周辺を含めた大まかな関係性は以下です。実際には internet facing な境界には LB や API Gateway などが配置されていたり、アプリケーションは各自DBを持っていたりしますが、ここでは省略しています。
Ory Hydra を用いた場合のシーケンス
認可コード発行の流れを簡略化して示すと以下です！
説明のために詳細を簡略化してる部分もあるので、詳しく知りたい方は https://www.ory.sh/docs/hydra/reference/api のドキュメントなどを参照ください。
なお Hydra から ID Service にリダイレクトなどしている箇所がありますが、ここは向き先のエンドポイントを自由に設定可能です。
上記のシーケンスをみると、多くの処理を Ory Hydra がこなしてくれることがわかりますね！
各種チャレンジの生成や state の検証などは Hydra 側が担当してくれます。
こちらとしては、基本的には認証と認可への同意の機能をもてば良いです。
このとき Hydra が付与するパラメータをキーに Hydra 側の状態を確認したり、渡されたパラメータをそのまま後続の処理に伝搬する必要がありますが、基本的には Hydra の仕様を確認しつつ対応すればOKです。
既存システムで追加実装が必要な点
大きく分けて以下2点です。
- hydra 経由で呼び出される認証や認可への同意の際、結果を適切な方法で hydra と連携する
- 認可のための scope 体系の整理、保護リソースへの適用
前者は hydra のドキュメントなどみれば必要なエンドポイントなどは把握できると思います。
基本的には受け取った login_challenge などの各種パラメータをキーに、その検証やある操作をスキップできるか確認しつつ、認証や認可への同意にまつわる情報を hydra 側に共有してあげればよいです！
流れのイメージには先ほどの大まかなシーケンスも参考になると思います！
後者についてはそれはそうだろという感じなのですが、結局あるリソースをどのような体系で認可を与えて保護したいかを決めるのはそのリソースオーナーないしはサービス提供者です。そのため当たり前なのですが、この部分は自分たちで設計する必要があります。
scope 設計もそれはそれで難しく課題があるのですが、それは別の機会に譲ります。
バクラク事業部での利用例など
バクラク事業部では、外部向けAPIの認可などを管理するために Ory Hydra を利用した OAuth2.0 認可サーバーを提供しています！
外部向けAPIの構成は以前紹介したこちらの記事をご参照ください。
また、直近リリースされたPCログにおいても、実はログ収集のためのデスクトップアプリにて 1st party として同じ仕組みを利用しています！
さいごに
今回は Ory Hydra の紹介と、それを用いたバクラク事業部での事例を紹介しました。
状況にもよりますが、すでにID管理を自前でやってるプロダクトにとって、個人的にはかなりバランスのよい選択肢だと思っています。
規模の大きいソフトウェアでの採用実績もあるので、もし OIDC や OAuth2.0 への対応が必要になったときはぜひご検討ください！
弊チームでは、IDや組織情報に関連するシステムを取り扱っています。
絶賛採用中ですので、こういう話がすきな人はぜひ〜！
Views: 2
