はじめに
スマートキャンプ株式会社京都開発拠点では、自社開発プロダクトであるSaaSマッチングプラットフォーム「BOXIL SaaS」とオンラインイベントサービス「BOXIL EVENT CLOUD」の間でアカウントを共有する共通ID基盤の開発を進めています。
この記事では、その開発過程でOpenID Connect（OIDC）の採用を検討した結果と得られた知見について解説します。
具体的には、共通ID基盤の開発過程を時系列で紹介し、OIDC採用の検討過程、ビジネス要件との折り合いをつけることが難しかったこと、およびOIDCを使わないケースも含めたシングルサインオンの代替案についても触れます。
対象読者
- ID基盤を作る際に、OIDCを導入しようか迷っている人
- かつOIDCの基本的なことは理解している人
主なキーワード
- BOXIL SaaS: SaaSマッチングサービス。主力プロダクト。
- BOXIL EVENT CLOUD: ビジネスのための情報共有の場としてのオンラインイベントプラットフォーム。
- OpenID Connect（OIDC）: 認証基盤としての最有力候補技術。
- シングルサインオン（SSO）: 一つのID（アカウント情報）を入力するだけで、連携する他のサービスにもログインできる仕組み。
- OpenID Provider（OP）：OIDCにおけるユーザー認証のサービスを提供するサーバーまたはプラットフォーム
- Relying Party（RP）：OIDCにおけるユーザーの認証情報を利用するサービスやアプリケーション
共通ID基盤プロジェクトについて
なぜプロジェクトを開始したのか？
プロジェクトの対象サービスがBOXIL SaaSというサービスと、BOXIL EVENT CLOUDというサービスであることは冒頭にお伝えしました。
BOXIL SaaSとBOXIL EVENT CLOUDとは、別々のサービスではありますが、片方はSaaSを導入したい／提供したい企業向けのマッチング、もう片方はイベント開催を通してビジネス上の知見・つながりを提供しています。 ですのでターゲットとする顧客としてはある程度重なる部分もあります。
現状ではそれぞれ独自の認証システムを持っているので、ユーザーは各サービスで別々に登録する必要があり、サービス間のデータ連携もありません。一方のサービスに登録しているユーザーに対して、そのデータを活用したもう一方のサービスで便利な機能を提供するなどの施策を簡単に提案できない状況でした。
このような課題を解消するため、共通ID基盤の導入により、一度登録すれば複数のサービスでアカウントを共有できるようにするプロジェクトがスタートしました。
ここで現状におけるサービスの簡単な構成図をお見せしておきます。 それぞれのサービスがユーザー情報を独立して持ち、認証も別々に行なっていることがわかります。
では現状を踏まえたうえで、要件をまとめていく次のステップに移ります。
共通ID基盤構築の要件
チームでは、ビジネスサイドのメンバーとも話を進め、共通基盤に求められる具体的な要件をまとめていきました。
要件をかいつまんで説明すると下記のような内容になります。
- ドメインの異なる2サービス（BOXIL SaaS、BOXIL EVENT CLOUD）でIDを統合して利用できるようにする
- もともとユーザー属性の近いサービスであるため、IDの一元化によりサービス間での相互送客を狙いたい
- 会員情報の二重入力や更新の手間を省き、サービスのUXを向上したい
- 各サービスのデータを紐づけたうえで、データ分析やマーケティング活動に活用したい
- 属性の近い別のサービスを将来的に連携する際のID連携の基盤を作る
- 新規サービスにおいても、既存サービスのユーザーを低コストで連携できるようにしたい
本プロジェクトでは上記の要件を満たすべく、まずは関連する技術選定から始めていきました。
共通ID基盤の技術選定
認証基盤に関連する技術群
今回のように異なるドメインのサービス間でのSSOを実現する際に、関連技術をいくつかピックアップし検討していきました。
以下に主要な検討技術をピックアップして簡単に特徴を説明します。
- OAuth2.0を拡張し、認証にも利用できるようにしたプロトコル
- IDトークンを用いて認証をして、UserInfoエンドポイントからユーザーのプロフィール情報を取得する
- 異なるドメインのサービス間でのSSOが実現できる
- データのやり取りはJSON形式で行なう
- 認可のためのプロトコル（認証ではない）
- この仕様で認証を賄うには独自に拡張を行なう必要があるが、リソースサーバーから提供されるプロフィールAPIを用いての認証の方法には脆弱性があり、拡張の際にはセキュリティなどのリスクに特に気をつける必要がある
- データのやり取りはJSON形式で行なう
- 異なるドメインのサービス間でSSOを実現できるプロトコル
- SAMLは独自に定義された認証規格であり、OIDCがOAuth 2.0に基づいているのとは対照的
- SAMLはXML形式でデータをやり取りする
独自構築
規格には属さないものの、完全に独自で認証システムを設計する選択肢も存在します。この方法は、特定の要件に対してもっとも柔軟に対応できる点が強みです。しかし、OIDCなどセキュリティも考慮された規格とは異なり、セキュリティリスクも自分たちで考慮の上仕様を決める必要があるため、その点で難易度が高いと言えます。
さらに、この手法は既存のライブラリや参考資料が少ないため、構築と運用のコストが他の方法よりも高くなる可能性があります。
どの技術を使うべきか？
チームでは、先にまとめた既存規格の技術、独自認証などの特徴と、求められる要件を考慮したうえで検討した結果、今回の共通ID基盤プロジェクトにおいては第一候補としてOIDCを採用することになりました。
選定の際に考慮した点については下記の通りです。
社内のスキルセットとのマッチング
- OIDCはOAuth2.0の拡張であり、基本的なフローはOAuth2.0とほぼ同じであること
- 既存プロダクトではOAuth2.0の導入実績があり、社内で知見がある程度蓄積されていること
低い複雑性
- SAMLよりもプロトコルがシンプルで、仕様自体の見通しが良いこと
- 走り出しから継続して検討をしながら進めていくような今回のプロジェクトには、シンプルであることがプラスで働くこと
- 将来的に新しいサービス連携することを考慮したときに、スピーディに連携できそうなこと
セキュリティの考慮
- IDトークンの署名・暗号化や、PKCE（Proof Key for Code Exchange）など、多くのセキュリティ機能とベストプラクティスが組み込まれており、必要十分であること
ライブラリの充実
- 標準化され多く利用されている規格であるため、既存のライブラリやツールのサポートが豊富で、設定例やドキュメントも充実していること
基盤のベースの技術としてOIDCを採用したので、それを前提としてシステム構成を考えていきます。
アーキテクチャの検討
次にOIDCを前提として、共通ID基盤を入れたときのサービス全体のアーキテクチャを検討しました。下記に簡略化した構成図を掲載します。
現状のシステム構成図は「なぜプロジェクトを開始したのか？」の章を参照してください。大きく変わったところは下記です。
- 認証を担う機能を共通ID基盤として新たに構築する
- BOXIL SaaS、BOXIL EVENT CLOUDでそれぞれ持っていた認証の実装を、共通ID基盤のOIDC経由で行なう実装に置き換える。
- 各サービス上にあるユーザー情報のうち、認証に使う情報を中心に共通ID基盤に移す。（それ以外の多くのサービス固有のユーザー情報は据え置き）
OIDCの観点だと、BOXIL SaaS、BOXIL EVENT CLOUDの各サービスはそれぞれRPとなり、新しく作る共通ID基盤はOPとして振る舞う形になります。
隠れたサービス要件の発覚
チームでは、作ったアーキテクチャの想定を元に、実際にOIDCを使ったときに具体的にどのような画面遷移になるだろう？実際のUXはどうなるだろう？といったユーザー観点での調査を重ねて、ビジネスサイドとも話を進めていきました。
サービスに求められる要件について
ところで、BOXIL SaaSでは、さまざまな施策を通じて会員の獲得効率（CVR）を最大限に高める戦略を採っています。たとえば、資料請求フォームの入力後に会員登録処理と並行してログインができるよう実装したり、EFO（Entry Form Optimization）によるUXの最適化に重点を置いています。
今回のプロジェクトでも、会員登録の手間を減らしてUXを向上したり、サービス間での相互送客を実現するなどの目的がありますが、実際問題としてはCVRを損なわないという前提条件下で考慮される必要があります。
ただ、この要件は事前に明文化できていたわけではなく、チーム間で明確に認識の形成ができずにプロジェクトが進行して、徐々に懸念が強く浮き彫りになってきたという感じでした。
OIDCで必須のOPへのリダイレクト
OIDCの仕様の中にはいくつかの認証フローが定義されていますが、特に今回採用を予定していた認可コードフローにおいては、"OPへのリダイレクト"という仕様があります。
下記のシーケンス図をご覧ください。
認証の開始時にRPであるBOXIL SaaSから、OPである共通ID基盤にリダイレクトされ、認証が完了した後にOPからRPに認可コード付きでリダイレクトされて戻ってくる流れがあることがわかります。 このリダイレクトはOIDCの仕様上重要で、RPとOP間の疎結合性を保つことで、安全に認可コードをRPに渡すことを実現しています。
OIDCとサービス要件の不一致
さて、前述したように、BOXIL SaaSとしては会員獲得におけるCVRに影響を与える変更は極力避けたい事情がありました。プロジェクトチームでは、OIDCのリダイレクト仕様がBOXIL SaaSのCVRにどのような影響を与えるかを慎重に考察しました。
結果、リダイレクトを入れることで会員登録やリード獲得のプロセスに影響が生じ、ユーザーが外部の認可エンドポイントへ移動することで、会員獲得の動線が分断されて、CVRやEFOによるユーザー動線の最適化にも悪影響を及ぼす懸念が出てきました。
それを避けるために、なんとかリダイレクトしつつも極力CVRに影響を与えない次善策を含め、調査と検討を重ねたのですが、決定的な策が提案できず、最終的には独立した共通ID基盤経由でOIDC認証をする構成を採用しない決断をしました。
高い自由度のUXを確保するために、OIDCのリダイレクト要件は今回のプロジェクトには合わないと判断したのです。
別の方法を探る
では、前述した「リダイレクトしたくない」というビジネス要件と、「リダイレクトが必要」というOIDCの仕様を受けて、どういった意思決定をすべきでしょうか。
私たちが現状調査・検討してきた案をいくつかご紹介します。
- BOXIL SaaSをOPとする案
- サービスのドメインを統合する
- サービスをコードレベルで統合する
なお、この記事を執筆時点では、目下、案の検討を進めている途中のため、どれを採用したのかは言及しません。どの案もUI/UXへの影響や、開発・保守運用工数への影響などなどトレードオフがあり影響度も大きいため、慎重に検討を進めていく必要があります。
また考えるうえでは、短期的なメリット、中長期的なメリットなど時系列も含めて議論が必要と考えています。
以下にそれぞれを簡単に紹介します。
1. 主力プロダクトをOPとする案
この案はOIDCの認証を管理するサーバー（マイクロサービス）を新規で開発・運用するのではなく、考慮すべきビジネス要件が多いBOXIL SaaSをOPとして振る舞わせ、BOXIL EVENT CLOUDはRPとしてそのエンドポイントを利用する形です。
そうすることでBOXIL SaaSでは従来の会員登録のフローを変更する必要がなくなるため、ネックだったリダイレクトの影響に対する懸念は考えなくて良くなります。
デメリットとしては、認証機能自体のBOXIL SaaSへの依存が強くなってしまうため、連携するサービスの負荷でBOXIL SaaSも影響を受けてしまったり、例えばBOXIL SaaSがクローズする際に連携サービスが影響を受ける可能性などがでてきてしまいます。
また、この案は一度しか使えず、今後連携するサービスでは通常のOIDCによるリダイレクトが強制される形になります。
以降の案はOIDCを使わない案です。
2. サービスのドメインを統合する
一方のサービスのコードベースを、もう片方のドメインに丸ごと移すやり方です。
例えば、BOXIL SaaSは現在 boxil.jp 、BOXIL EVENT CLOUDは boxil-event-cloud.jpでホスティングしていますが、これを boxil.jp 、 event.boxil.jp に変更すれば、サードパーティクッキーの制限がなくなります。
片方でログインして、もう片方のサービスとログインセッションを共有することも技術的に可能になります。
3. サービスをコードレベルで統合する
これはできるケースが限られると思いますが、もし連携するサービスのビジネスドメインや会員属性が近く、数が多くない場合は、サービス自体を一つのコードベースに統合する案も考えられそうです。
当然ながら自由度は非常に高いですが、引越しする側のサービスについてゼロベースに近い開発が必要になるため、完了までにかかるコストや、統合にあたっての双方のデータスキーマの見直しなど、多岐にわたる検討が必要になります。
終わりに
本プロジェクトの開発過程では、技術選定だけでなく、ビジネス要件との整合性も重要であることが明らかになりました。OIDCは多くの場合に有効な技術ですが、それありきで進めるのではなくUXとビジネス要件をしっかりと両立させ、最適な技術選定と実装を広い視野で追求していく必要があることを今回学ぶことができました。
この記事が皆さまの参考になれば幸いです。
