STORESにおける OpenID Connect/OAuth 2.0の活用

Transcript

1. STORESにおける
 OpenID Connect/OAuth 2.0の活用 大久保彰彦 

2. 自己紹介: 大久保 彰彦
 • ID基盤や各サービスの統合周りの開発などを担当 • 比較的バックエンド、インフラ寄り • 主にGolang、Railsで開発してます • 歴史好きでYouTubeチャンネル『COTEN RADIO』推し
3. イントロダクション
 
 なぜSTORESにOpenID Connect/
 OAuth 2.0が必要
 だったのか

4. STORESは複数の事業会社が集まって作られた
 当然アプリケーションも DBも
 クラウドもバラバラ 

5. 独立したサービス群を「ひとつのSTORES」として繋ぎ合わせるために、
 シングルサインオン (SSO)やセッションマネジメント 、
 サービス間通信の一貫した認可 が必要。

6. そのためにIdPを作成
 ID基盤「STORESアカウント」を作成し、全サー ビスに導入。
 
 • OpenID Connect/OAuth 2.0に準拠
 • SSOを実現
 • セキュアな認証や認可Tokenの発行

7. 本発表の内容
 IdP = STORESアカウントの活用事例を大きく二つ紹介します。
 1. 複数サービス間のSSO（シングルサインオン）での活用
 2. サービス間通信の認可での活用

8. 軽く用語整理
 IdP(ID Provider)
 OIDCに基づく認証処理やOAuth 2.0に基づくトークン発行機能を持つ ID 基盤
 RP(Relying Party)
 予約やネットショップなど、IdPを利用して認証・認可を受ける
 各サービス
 ID Token
 OIDCで定義されている、認証情報を表す Token
 Access Token
 OAuth 2.0で定義されている、認可用Token
 Refresh Token
 OAuth 2.0で定義されている、Access Tokenを再発行するためのToken
 認可コードフロー
 ユーザーがサービスにログインする際、 IdPで認証後に認可コードを取得 し、RPがそのコードを使ってtokenを安全に取得するフロー

9. 複数サービス間の SSOでの活用

10. 話したいこと
 • STORESアカウントのログインセッションを用いたシングルサインオン(SSO) の仕組み
 • Back-Channel Logout、Front-Channel Logoutを用いたシングルサイン アウトの仕組み

11. SSOの実現
 1. RP→IdPへ認可リクエスト
 2. IdPのログインセッション があ れば認証情報入力をスキップ して認可コードを発行する
 3. RPは認可コードフローで tokenを得る
 4. RPはそれぞれログインセッ ションを発行する

12. 突然ですが、みなさんの開発しているシステムで、
 ログインセッションがずれたことはありますか？

13. まずログインセッションずれの説明
 各サービスから単純に個別にログ アウトできる方式だと、サービス間 でログインしているアカウントが揃 わないことがある。 認可エラーや、意図しないアカウン トでの操作を誘発。
14. シングルサインアウトが必要
 ログアウト連携 (シングルサインアウト )が必要。 OIDCで以下の仕様が定義されているので活用する。 OpenID Connect Back-Channel Logout 1.0 OpenID Connect Front-Channel Logout 1.0
15. Back-Channel Logout = IdPをログアウトした時にRPもログアウトする仕組み
 1. IdPのログインセッションごとに 一意のsidを発行 2. sidを認可コードフロー内でRP に永続化 3. ユーザがIdPをログアウトした 際、sidをRPに通知 4. RPはsidに紐づくログインセッ ションを破棄
16. Front-Channel Logout = RPをログアウトした時にIdPもログアウトさせる仕組み
 1. RPをログアウト。ログインセッ ションを破棄 2. IdPのログアウト連携URLへリ ダイレクト 3. IdPをログアウト 4. IdPからRPのPost Logout URLへリダイレクト
17. 複数サービス間のSSOでの活用: まとめ
 • 標準に従って仕様通りに実装することで、複数のサービスにまたがるセッ ションのマネジメント戦略をセキュアに実現できる • Back-Channel Logout、Front-Channel Logoutを正しく実装することで、 サービス間を遷移した時に、意図せずアカウントが切り替わることがなくな り、統合された体験を実現できる
18. サービス間通信の 認可処理での活 用

19. 「統合されたSTORES」らしい機能を開発するにはサー ビス間の通信 が不可欠。

20. • 複数のAPIから売上を取得 • APIがさらに別のAPIを呼び出 すことがある 例: ネットショップと予約と決済の売上げの合計を画面に表示したい場合

21. • セキュリティリスク • 無限ループの危険 • 障害発生時の影響範囲が見 通せない
 サービス間の直接通信を許容してしまうと...

22. 各サービスはAPI-Gatewayを介して通信する
 • Access Tokenを使って認可 • API-Gatewayは認可されたリ クエストのみバックエンドへ転 送 • ゼロトラストなアプローチに基 づき、一貫した認可処理を実 現
23. 一貫しているものの運用上では多くの問題に直面
 実際に起きた課題に対するSTORESでの対応を紹介 • Refresh Tokenの無効化戦略の見直し • 一貫したアクセス制御の難しさ • 障害発生時のトレース困難
24. 1: Refresh Tokenの無効化戦略の見直し

25. みなさんの開発しているシステムで、
 大量のセッションが突然ログアウトされたことはありますか？

26. 実例: Token Refreshのレースコンディションによる大量ログアウト
 • 当時のIdPの仕様
 ◦ Refresh Tokenは一度の 利用で無効化
 ◦ 無効化済みのRefresh Tokenが利用された場合 エラーとし、Grant(認可フ ローで得た権限)ごと破棄 ≒ログアウト

27. Refresh Tokenを一定期間再利用可能として対応
 • 一定期間のRefresh Tokenの 再利用を許可
 • 例えばGoogle OAuthでは、 Refresh Tokenは明示的な Revokeか、一定世代以上古 いものから無効化
 • 利便性とセキュリティの妥当 なトレードオフ 

28. 2: 一貫したアクセス制御の難しさ

29. 認可スコープを活用して一貫したアクセス制御を実現したい
 • RFC6749 - Access Token Scopeで定義されている認可 スコープを利用
 • Tokenが持つスコープを利用 してAPI-Gatewayで認可制御 を行う
 • STORESではこの方式を採用

30. みなさんは、あるAPIを実行するときに、
 そのAPIの内部でさらに呼び出されるAPIを
 網羅的に把握できますか？

31. 認可スコープを利用したアクセス制御による開発負荷の増加
 • システムが複雑になるにつれ 開発負荷が増加
 ◦ 開発者の認知の限界
 • 十分な認可制御には各サー ビスでの認可処理が必要
 ◦ 認可スコープの形骸化

32. 一貫したアクセス制御と開発効率のトレードオフ
 • STORES内部のサービスが使うOAuth Client限定で、認可スコープチェック をスキップ
 • API-Gatewayでの一貫したアクセス制御はある程度諦める
 • 現時点では開発効率向上のメリットの方が大きく妥当なトレードオフ
 
 (補足)
 ※STORESは3rd Party向けの外部公開APIの提供も行っており、そちらは認可 スコープのチェックを継続

33. 3: 障害発生時のトレース困難

34. あるAPIを呼び出した時に、
 「internal_server_error」というレスポンスが返りました。
 呼び出し先のAPIのログを確認すると、また別のAPI呼び出しでの エラーログを見つけました。
 
 原因に辿り着くまでこれを繰り返すことに耐えられますか？

35. 分散トレーシングとは
 
 • 複数のサービスをまたいで処理されるリクエストの処理フローを可視化・追 跡する技術
 • Trace IDやSpan IDを使ってサービスを跨ぐリクエストをトレースする
 • 遅延やエラーの発生箇所を特定するために便利
 • 代表的な実装やサービスとして OpenTelemetry、AWS X-Ray、Cloud Trace、Datadog APM などがある
 
 複数サービスに跨る通信の障害調査には分散トレーシングが有効

36. 分散トレーシングを活用したトレーサビリティの確保
 Datadog APMを活用してAPI Call Stack全体の分散トレーシン グに対応。 • リクエストを処理するために利 用したサービスが一覧で分か る • 障害発生点のログまですぐに 辿り着くことができる
37. サービス間通信における認可での活用: まとめ
 • OAuth 2.0のTokenを用いて一貫した認可処理を実現している • 実用する上では運用に合わせた設計・トレードオフが必要だった ◦ Refresh Tokenの無効化戦略を緩和し、一定期間再利用可能とする ◦ 認可スコープによる認可制御を一部オミット ◦ 分散トレーシング(Datadog APM)によるトレーサビリティの確保
38. 全体まとめ
 • OpenID Connect/OAuth 2.0に準拠することで、複雑なアーキテクチャを手 早くセキュアに実現することができる • 実際に運用する中では、利便性や開発効率を向上させるための現実的なト レードオフ戦略が必要
39. 今後の課題
 • 各所のオーバーヘッドを取り除いてパフォーマンスを改善する • サービス間で共通で利用するドメインの切り出しなど、リソースの最適配置 • 深くネストした呼び出しや再帰呼び出し箇所のリアーキテクチャ STORESはこれらの課題に共に立ち向かう仲間を積極募集中です！！ご興 味ある方是非お声かけください！