スモールチームがAmazon Cognitoでコスパよく作るサービス間連携認証

(Speaker Deckはハイパーリンクが消えてしまうので、PDF版はこちら: https://drive.google.com/file/d/16C2-5ZU-uovNzYnT__3_ufHtylPj49R6/view?usp=sharing )

SaaS.tech #3 登壇資料 https://saas-tech.connpass.com/event/247653/

Amazon Cognitoを用いてOAuth 2.0のAuthorization Code Grantを用いた認証フローを実装し、Open ID Connectに対応した連携ID Providerを追加することで複数の認証手段を提供する方法について紹介。またCognitoを用いたm2m (machine to machine)認証についても紹介します。

Transcript

1. 1 © 2022 LayerX Inc. LayerX Inc. スモールチームがAmazon Cognitoでコスパよく作るサービス間連携認証 武市 融紀 SaaS.tech #3 2022.5.19
2. 2 © 2022 LayerX Inc. 自己紹介
3. 3 © 2022 LayerX Inc. 2014年4月 株式会社ミクシィ入社。株式会社ノハナに出 向し、主にサーバーサイドのエンジンリアリングに従事。 Parse.comからGCPへのインフラ移行などを経験。 2017年4月 株式会社ノハナCTOに就任し、全社の技術 統括・エンジニアリング組織のマネージメントに従事。 2020年3月 株式会社LayerX入社。三井物産デジタル・ アセットマネジメントに出向。プロ向け投資プラットフォー ムALTERNAの企画・開発に従事後、現在は不動産ファ ンドの期中運用のDXを推進・従事。 武市 融紀 (twitter: @tacke_jp) 株式会社LayerX シニアソフトウェアエンジニア 自己紹介
4. 4 © 2022 LayerX Inc. SaaS・Fintech・Privacy Techの3つを軸にすべての経済活動のデジタル化に取り組む。 (参考)https://note.com/fukkyy/n/n424bfb022b33 LayerXの3つの事業
5. 5 © 2022 LayerX Inc. 今回の課題の背景
6. 6 © 2022 LayerX Inc. アセットマネジメント事業の特性 三井物産デジタル・アセットマネジメント(MDM)では、物件情報を受け取って実際に投資、その後運用す るまでにPMや会計事務所、不動産仲介などのパートナーや社内の複数のチームが連携することにな り、それぞれに合わせたWebアプリケーションを利用します。 ソーシング 組成・販売 ファンド運用 不動産仲介会社・売主 AM(MDM) PM/会計事務所..etc 投資家 情報 提供 不動産評価 売却 購入 IR確認 物件 管理 IR 運用・承認 契約
7. 7 © 2022 LayerX Inc. AMに関わる複数プロダクトの連携 今回の課題背景として、物件情報の取得・管理・評価を行うシステムと証券を販売するシステム、ファン ドを運営・管理するシステムの連携があります。そのため、管理者・利用者・システム間(m2m)という3つ の認証が求められました。 物件管理くん DAM（Digital Asset Management） ALTERNA 証券販売・勧誘を主とする投資 家向けサービス 商品ショーケース 物件情報を収集・評価するソー シング用ツール 組成されたファンドの情報管理・ 運用効率化ツール 物件情報 提供 運用・報酬 情報提供 物件情報 提供 MDM販売担当 (外部)投資家 MDM運用担当 MDM取得担当 (外部)管理会社 (外部)不動産仲介
8. 8 © 2022 LayerX Inc. 開発を取り巻く環境 スモールチームが社内や関係会社向けに提供するWebアプリの開発を行う際の課題感に近い 複雑な認証フローを実装する必 要。また高いセキュリティ要件が 課される部分。 認証手段を車輪の再発明的に作 り込んでいくと、コストが徐々に積 み上がっていく。 認証・認可の実装コスト プロダクトの開発初期は３〜４名 のスモールチームであることが多 い。 一方で認証・認可は、初期の設計 がその後の開発に大きく影響する 部分。 開発初期の少ないリソース 昨今の情勢を踏まえるパスワード のみの認証は避け、MFAなどを サポートしたい。 個別プロダクトごとにpwなどの認 証情報の管理をしたくない。 認証手段の複雑化とその管理
9. 9 © 2022 LayerX Inc. 技術選定の結果 & 実際の画面の紹介
10. 10 © 2022 LayerX Inc. Amazon CognitoをID Providerとして選定 Amazon Cognitoが要件を満たし、我々にとってhandyな選択肢だったのが大きな理由 以下の各種flowが実装されてお り、十分実用に耐えると判。 • Authorization Code Flow • Implicit Flow • Client Credentials Flow OAuth2.0各種flowに対応 OpenID ConnectやSAML2.0に 準拠したID Providerを登録するこ とで認証手段を増やすことがで き、パートナー各社の認証手段に 対応できる。 • Google • Azure AD • Okta • OneLogin … etc 複数のID Providerを利用可能 既にAWSを利用している場合は、 追加の契約なく利用出来るため 楽。またTerraformなどでのIaC化 が容易。さらにAWSの他のリソー スと連携し認可サーバーとしても 利用可能。 AWSの1リソースである
11. 11 © 2022 LayerX Inc. デモ動画 - DAMのログイン画面
12. 12 © 2022 LayerX Inc. Cognitoを用いた認証フローの実装
13. 13 © 2022 LayerX Inc. 全体のアーキテクチャと認証フロー Browser My Application Server Cognito (4) ID Token取得 (1)認証 URLの 発行 (2)認証 の 実施 (3) Authz Code の送信 (6) Cookie Session の発行 OAuth 2.0 for Browser-Based Apps (RFC ドラフト) の Application Architecture Patterns にある JavaScript Applications with a Backend に準拠 ポイント • Authorization Code Flowを実装 • Browserは直接 ID Tokenを受け取ら ない • Application ServerはCookie Sessionを発行し、以後そのCookie を利用してAPI認証を実施 (5) ユーザー 情報の保存
14. 14 © 2022 LayerX Inc. OAuth 2.0 Authorization Code Grantを用いたDAMの認証フロー
15. 15 © 2022 LayerX Inc. サンプル実装 (Go) github.com/zitadel/oidc (OIDC認証済ライブラリ) を用いたサンプル実装 ※ state, PKCE challenge, nonce (Cognitoでfederated IdP利用では必要) のparam付与が別途必要な点に留意
16. 16 © 2022 LayerX Inc. 他の認証フローとの比較 バックエンドでユーザー情報を管理する前提であり、SessionStorageへのID Token保持するなど認証 情報をフロント側で管理するのを避けたく、今回はバックエンド連携型の認証フローを採用 認証完了後の遷移先にURLのqueryパラメータに authorization codeが埋め込まれる。サーバーを 介してIdPにそのコードを送信することでIDToken を取得することができる。 その後はCookieを用いてBackend側のAPI認証 を行う。 ★ バックエンド連携型 認証サーバーからの遷移時に直接 URLの fragmentにIDTokenが埋め込まれる形(Implicit Grant)。JavaScriptでの直接処理を前提としてい る。 各IdPが提供するJS SDK (e.g. Cognitoの場合 はAmplify) を用いて認証するパターンが多い。 取得したID TokenやAccess Tokenなどは必要に 応じてインメモリやSessionStorageなどで保存さ れ、その後の処理に活用される。 フロントエンド完結型
17. 17 © 2022 LayerX Inc. ID TokenをFrontendが直接取得するフローの例 Browser (SPAなど) ID Provider (2) ID Tokenの 送信 (1)認証 の 実施 SPA単独で認証認可フローが完結するのであ れば使いやすいが、ID Providerから取得した ユーザー情報をバックエンドに永続化したい場 合には少し煩雑なフローとなってしまう。 (3) 認証情報の保 存 My Application Server (4) ID Tokenの送信 (5) ID Token検証 (6) ユーザー情 報の保存 (0) 公開鍵な どの取得
18. 18 © 2022 LayerX Inc. サービス間連携認証
19. 19 © 2022 LayerX Inc. サービス間連携 - 各ID Providerの立ち位置 DAM <-> Cognito間はOIDCで会話。OIDCやSAML2.0が喋れる各種IdPの追加が容易に行える。 OpenID Connect OpenID Connect OpenID Connect 自社のID基盤 （AzureAD） とある管理会社様の ID基盤 別のパートナー 企業様のID基盤 OIDC SAML2.0 m2m認証 m2m認証 DAM ALTERNA 物件管理くん Cognito
20. 20 © 2022 LayerX Inc. Cognito設定画面: (例)連携IdPとしてGoogleを追加 発行したclient id / secret を Cognito側に登録 Amazon Cognito ユーザープールでフェデレーション アイデンティティプロバイダーとして Google を設定す るにはどうすればよいですか？ に手順が詳しく書かれ てします consent screen の作成
21. 21 © 2022 LayerX Inc. 連携IdPからCognitoへのユーザー情報のマッピング Cognitoは、連携IdPが発行したID Tokenの中身をUser Poolに保存後、その情報を載せたID Tokenを アプリケーションに対して発行します。 連携IdPが保有しておりアプ リケーション側で活用したい ユーザー情報があれば、予 めCognito側にmapping設定 しておく。
22. 22 © 2022 LayerX Inc. m2m認証
23. 23 © 2022 LayerX Inc. 検討したm2m認証方式 直近のMicroservicesの進化で様々な選択肢が存在するが、今回は規模感やコスパの良さを踏まえ Cognitoでのm2m認証を採用 明確に分離したプロダクト同士を連携する必要がある 点、インフラ構成の変更が不要であり管理コストが低い 点、custom scopeなどを用いて細粒度の権限管理な どが可能な点などを踏まえ、この手段を採用。 ★ Cognito x OAuth2.0 でのm2m認証 AWSを利用しているため、 Security Groupで経路を保 護する方法。 ↓ 複数のAWSアカウントにまたがるなどで管理が現状の 手法と合わず見送り。 SecurityGroup等での制御 証明書を発行しつつ、経路暗号化を実現する。実装と してAPI Gatewayを挟むことを検討。 ↓ ・ACMでの証明書が多少高い（ $400） ・証明書refreshのopsが面倒 なため却下 mTLS + API GW Envoyを中心にService Meshを構築していく方法。 ↓ 現状のMDMにおいてはtoo muchと判断した Envoy Proxy
24. 24 © 2022 LayerX Inc. 全体のアーキテクチャ Machine User Application Server Cognito (0) 公開鍵などの 取得 (2) API リクエスト w/ Access Token (1) Access Token取得 (4) 制限され たリソース (3) Access Tokenの検証 認可サーバー(Cognito)の公開鍵を利用して、 Machine Userが送信してくるAccess Tokenの署 名を検証。必要に応じて scopeについてのチェック なども行う。 client secret
25. 25 © 2022 LayerX Inc. OAuth2.0 Client Credentials Grantを用いたm2m認証
26. 26 © 2022 LayerX Inc. まとめ
27. 27 © 2022 LayerX Inc. まとめ MDMにおいてCognitoを活用することで、異なるID基盤の提供する認証手段と、プロダクト間でのデータ 連携のためのm2m認証手段を実現した方法についてお話しました。 1 AWSを利用していればCognitoはhandyな選択肢。IaC化や他機能と連携ができる嬉しみも。 2 OIDC/SAML2.0を実装するCognitoをhubにすることで複数の異なるID基盤との連携を実現 3 独立した複数の社内プロダクト間でのm2m認証を提供する手段としてもCognitoを活用 4 認証/認可プロトコルは学習コストがあるが一度会得すれば色々と応用が効く知識
28. 28 © 2022 LayerX Inc. 参考資料 • OAuth 2.0 全フローの図解と動画 ◦ OAuth 2.0 の各種Tokenの取得フローを理解する上で大変参考になりました ◦ OAuth 2.0 の認可レスポンスとリダイレクトに関する説明 も合わせて読むのをお勧めします • OAuth 2.0 for Browser-Based Apps ◦ 今回認証フローを実装するにあたり、紹介されているアーキテクチャパターンを参考 にしました • ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 ◦ 混乱しがちなOIDCとOAuth 2.0の違いなどがわかりやすく解説されています • Why you should stop using the OAuth implicit grant! ◦ 認証フローを検討に際に Implicit Grantを利用する場合のリスクについて詳しく知る ために参考にしました ◦ 上記記事の日本語での解説記事 もあります • Certified OpenID Connect Implementations ◦ OpenID Foundationが認証したオープンソースの OIDC実装ライブラリが公開され ています ◦ github.com/zitadel/oidc もここで見つけました • Amazon Cognito ユーザープールでフェデレーションアイデンティティプロバイダーとして Google を設定するにはどうすればよいですか？ ◦ CognitoとGoogle (IdP) を連携する手順について解説されています
29. 29 © 2022 LayerX Inc. ご清聴ありがとうございました！