複数プロダクトを横断する共通ID基盤の開発

参考になった

レビュー投稿日の情報になります

株式会社Gaudiy / Takuma Katsumata

チームリーダー / バックエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名

最終更新日2025/10/27投稿日2025/10/28

利用プラン	利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
ビジネスプラン	認証認可機能	10名以下	2025年5月	B to C

利用プラン	ビジネスプラン
利用機能	認証認可機能
ツールの利用規模	10名以下
ツールの利用開始時期	2025年5月
事業形態	B to C

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

複数プロダクトを横断する共通ID基盤が事業戦略上重要になっていた。
その中でもOAuth 2.0/ OIDCに完全準拠しつつ、できるだけスピーディーに立ち上げたいというモチベーションが高かった。
また、ID領域に精通していたり、実務レベルで経験があるエンジニアが少ないなかで、IDプロダクトを開発していくことの懸念が大きかった

どのような状態を目指していたか

今後も新規プロダクトやGaudiyに新しく入ってくるプロダクトが増えていく中でも、シームレスな連携を行えつつ、高いセキュリティを保てるID基盤になる必要があった。

比較検討したサービス

Auth0
Ory hydra（self hosting）
フルスクラッチ

選定理由

開発導入のしやすさ

他のIDaaSはフルスタックなものが多い中で、OAuth2.0/OIDCに特化したIDaaSで、それ以外の部分はGaudiy側の要件に合わせて独自に柔軟にできる点。会社にはよるが、Gaudiyにとってはこの特化したIDaaSという点がマッチした。

コスト面

OAuth2.0/OAuthに特化したSaaSということもあると思うが、他IDaaSに比べて1ユーザーあたりのコストは比較的安いと考えています。（使い方にもよるかもしれないが…）

その他

最後までOry hydra（self hosting）と悩んではいました。
- Oryはhydra, kratos, Oathkeeperなど役割によってself hosting可能なOSSも提供しており、hydraはOry Stackの中でもOAuth2.0/OIDCに特化したOSSでauthleteに役割的にはかなり近い。
最終的な決め手はIDaaSというマネージドなサービスに任せられるという運用コストの低さと現状は使わないが将来使う可能性があるかもしれないスペックにAuthleteは準拠しているが、Oryは準拠していないという点で判断をしました。（2025/10/27。ただ、OryはかなりアーリーなRFCに全て準拠することよりも他にやるべきことがあるため、優先度を下げているという方針なため、あえて準拠していないみたいな側面もある）
- 例

導入の成果

改善したかった課題はどれくらい解決されたか

もちろんOAuth2.0/OIDCのRFCの読み込みや理解は必要だが、かなり早いスピードで認証・認可のミニマム必要な機能（Authorization Code Flow & PKCE、Token Endpoint、Revoke Endpoint、Userinfo Endpoint、Discovery Endpoint、JWKs、Introspection周り）は立ち上げることができた。

導入時の苦労・悩み

導入自体に苦労したことはそこまでないのですが、やはり一定スペックの理解をしていくことは必要だったり、自分達で考えないといけない点もあるので、そういった部分に関しての設計が苦労している点です。

導入に向けた社内への説明

上長・チームへの説明

基本的に、「決め手になったポイント」に書いた通りで、スケールしたときのコスト感や現実的に開発できるのか？という観点を話しながらチームで決めていった。

活用方法

よく使う機能

Authlete API ExplorerにあるAuthorization Endpoint、Token Endpoint、Revocation Endpoint、Introspection Endpoint、JWK Set Endpoint周りは利用しています。
あとは、再同意の判定やPairwise Identifierの生成のためにClient Management系のエンドポイントも利用しています

ツールの良い点

OAuth2.0/OIDCの幅広い仕様に準拠している
特化IDaaSの恩恵で既存のシステムに導入が非常にしやすい。

ツールの課題点

GoのSDKの品質は高くないかもしれない。（他言語に関しては見ていないので分からない）
- authlete v3を使っているため基本的には、https://github.com/authlete/openapi-for-go/tree/v3 を使うべきだが、openapi自体が間違っていたりするケースが何回かあった。そのため、社内でopenapiを微調整してclient sdkを生成している。