Amazon Cognitoを用いた認証・認可の基本

-- Views

December 24, 25

スライド概要

今後の社内システムやサービス開発における認証・認可技術の基礎固めを目的として、AWSが提供する認証・認可サービス「Amazon Cognito」を用い、基本的な構成の技術検証を実施しました。

エヌアイデイの若手メンバーが参加し、基礎技術の習得と実践的な経験を目的とした社内の技術検証取り組みの資料です。

株式会社エヌアイデイ

@NID_Tech

スライド一覧

株式会社エヌアイデイの公式アカウントです。ソフトウェア開発、システム構築、システム運用まで幅広いICTサービスを提供する、1967年創業の独立系IT企業です。 NIDエンジニアの社内取り組みや登壇資料を共有します。

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

AWS×Palo Alto VMFWで作るVPN接続環境

株式会社エヌアイデイ 2.7K

5時間で請求額95万円！？失敗から学ぶファイル転送基盤構築

株式会社エヌアイデイ 2.5K

【初心者向け】AWSで実践！Dockerで作るコンテナログ基盤

株式会社エヌアイデイ 1K

AWSマルチAZ×CLUSTERPROを用いた自動切替検証

株式会社エヌアイデイ >100

猫でも分かるUnreal Engineの学び方 - 超初心者向け編 - 2023 v1.0

ue4 ue5 ue-beginner

エピックゲームズジャパン 1.7M

Unreal Engine5 Lumenの仕組みと肝心なところ

ue5 ue-rendering ue-lumen

エピックゲームズジャパン 1.4M

各ページのテキスト

目次 1. 検証概要 1-1. 検証目的・内容 1-2. 構成 1-2-1. 構成図① 1-2-2. 構成図② 1-3. Amazon Cognito 2. 技術要素 2-1. OAuth 2-1-1. 共通構造 2-1-2. 認可フロー 2-1-3. Client Credentials Grant 2-2. OpenID Connect (OIDC) 2-2-1. 共通構造 3. 構築 3-1. 構築① 3-1-1. 構築①_Cognito 3-1-2.構築①_API Gateway, Lambda 3-2. 構築② 3-2-1. 構築②_Google IdP(Google Cloud) 3-2-2. 構築②_Googleとの連携 3-2-3. 構築②_Cognito 3-2-4. 構築②_API Gateway, Lambda 4. 検証 4-1. 検証① 4-2. 検証② 5. まとめ 2-2-2. 認証・認可フロー 2-2-3. Authorization Code Flow Copyright(c)2025 NID All Rights Reserved ※本資料に登場する会社名・製品・サービス名、ロゴマークなどは該当する各社の商号・商標または登録商標です。 3

1-1. 検証目的・内容 ◼ 検証目的・内容サイバー攻撃の激化・高度化に伴い、今後、認証・認可の重要性と需要が右肩上がりとなることが想定される。Amazon Cognitoを用いた基本的な構成を検証し、認証・認可の基礎技術の確認を行う。検証は以下の2つにわけて行う。【検証①】 API Gateway + Amazon Cognito 認可フロー: Client Credentials Grant (OAuth2.0) 【検証②】 Amazon Cognito + Google IdP Googleアカウントを使用したサインインの実装(OIDC) 4 Copyright(c)2025 NID All Rights Reserved

10.

1-3. Amazon Cognito ◼ Amazon Cognito AWSが提供する認証・認可サービス。外部IDプロバイダー(Google、Facebookなど)との連携をサポートし、ユーザ認証を一元管理する。以下の2つの主要なコンポーネントで構成される。 • ユーザプールユーザのサインイン/サインアップや認証成功後のトークン発行を行う • IDプールユーザの認証結果を受け取り、AWSリソースへのアクセスに必要なAWS認証情報を発行する ★検証ではユーザプールのみ使用 10 Copyright(c)2025 NID All Rights Reserved

11.

2-1. OAuth ◼ 認証通信相手が誰であるかを確認するプロセス。 ID/PWや生体認証などで、「ログインしようとしているのは誰か」を見る。 ◼ 認可リソースへのアクセスなどの権限を付与するプロセス。ユーザに対して「何ができるのか」を決定する。 ◼ OAuth とは認可の仕組みを提供するフレームワーク。 ID/PWなどの認証情報を渡すことなく、アクセストークンを用いてリソースへのアクセス許可を制御する。検証ではOAuth2.0を使用する。 ※アクセストークン: 保護されたリソースへアクセスを行うために使用されるトークン。特定のリソースに、限定された権限でアクセスするための証明書。 11 Copyright(c)2025 NID All Rights Reserved

12.

2-1-1. 共通構造 ◼ OAuth2.0の各認可フローで共通する構造リソースオーナ認可サーバ ① アクセストークンを取得する。 ① (※取得方法はフローにより異なる) ② トークンを用いてリソースへアクセスする。クライアント ② リソースサーバリソースオーナ：リソースの所有者クライアント：データを使いたいアプリやWebサイト認可サーバ：ID/PWを管理し、トークンを発行するサーバリソースサーバ：データの保管場所 12 Copyright(c)2025 NID All Rights Reserved

13.

2-1-2. 認可フロー ◼ OAuth2.0 トークン取得方法 1. Authorization Code Grant 認可エンドポイントから認可コードを取得し、トークンエンドポイントで認可コードとアクセストークンを交換する。サーバサイドのWebアプリで利用。 2. Implicit Grant 認可エンドポイントから直接アクセストークンを取得する。クライアントシークレットが隠せない環境で利用。 3. Resource Owner Password Credentials Grant リソースオーナのクレデンシャル(ユーザ名・パスワードなど)を利用してトークンを得る。クライアントと認証サーバ間の信頼性が高い場合に利用。 4. Client Credentials Grant ★検証で使用リソースオーナへの確認を行わずにトークンのやり取りを行う。ユーザ関与の無い、サービス間連携(マシン間通信)で利用。 13 Copyright(c)2025 NID All Rights Reserved

14.

2-1-3. Client Credentials Grant ◼ Client Credentials Grantの認可フロー ※クライアントはコンフィデンシャルクライアント (機密クライアント)である必要がある。コンフィデンシャルクライアントは、その認証情報 (クライアントシークレット)を秘密にしておくことができるタイプのクライアント。 (対義語: パブリッククライアント) 14 Copyright(c)2025 NID All Rights Reserved

15.

2-2. OpenID Connect (OIDC) ◼ OIDC とは OAuth2.0をベースに認証の仕組みを追加したプロトコル。アクセストークンに加えてIDトークンを発行し、ユーザのID情報やログイン情報を安全にやり取りできるようにする。 ※IDトークン: ユーザが誰であるかの情報(ユーザ名、メールアドレス等)を含んだトークン。クライアントはIDトークンを確認することで認証が成功したかを検証する。 15 Copyright(c)2025 NID All Rights Reserved

16.

2-2-1. 共通構造 ◼ OIDCの各認可フローで共通する構造 ① クライアント(アプリ)上でデータアクセスを伴う ③ エンドユーザ IdP ④ トークンを発行する。 ② クライアント ② IdPへ認可要求を行う。 ③ ユーザ認証とアクセス認可を行う。 ④ ① 操作を行う。 ⑤ リソースサーバ (※発行方法はフローにより異なる) ⑤ アクセストークンを用いてリソースへアクセスエンドユーザ：サービス利用者する。クライアント：データを使いたいアプリやWebサイト IdP：ユーザの本人確認を行い、トークンを発行するサーバリソースサーバ：データの保管場所 16 Copyright(c)2025 NID All Rights Reserved

17.

2-2-2. 認証・認可フロー ◼ OIDC トークン取得方法 1. Authorization Code Flow 認可エンドポイントから認可コードを取得し、トークンエンドポイントで認可コードと IDトークン・アクセストークンを交換する。サーバサイドのWebアプリで利用。 2. Implicit Flow 認可エンドポイントから直接IDトークンとアクセストークンを取得する。クライアントシークレットが隠せない環境で利用。 3. Hybrid Flow Authorization Code FlowとImplicit Flowを組み合わせたフロー。「認可コードと一部のトークンを認可エンドポイントで取得し、残りのトークンをトークンエンドポイントから受け取る」といった動きができる。 17 Copyright(c)2025 NID All Rights Reserved

18.

19.

20.

3-1-1. 構築①_Cognito ◼ Cognitoユーザプール設定 ※UI・設定項目は検証当時(2023年)のものユーザプール test-userpool リソースサーバ <resoueceserver> カスタムスコープ <resoueceserver>/<customscope> アプリクライアント test-client01 ID XXXXXXXXXXX シークレット YYYYYYYYYYY アプリクライアント test-client02 ID WWWWWWWWWW シークレット VVVVVVVVVV アプリクライアント test-client03 ID SSSSSSSSSS シークレット - <resoueceserver>/<customscope> 実際の値はアプリクライアント作成時に発行されたものシークレットなしのクライアントとして作成 20 Copyright(c)2025 NID All Rights Reserved

21.

3-1-2. 構築①_API Gateway, Lambda ◼ API Gateway, Lambda設定 ※UI・設定項目は検証当時(2023年)のもの /api API名 test-API プロトコル HTTP API ID QQQQQQQQQQ APIエンドポイント https://<API ID>.execute-api.ap-northeast-1.amazonaws.com/api 実際の値はAPI Gateway作成時に発行されたもの API Gateway XXXXXXXXXXX(test-client01のID) Lambda 対象者以外からのアクセスは拒否される 21 Copyright(c)2025 NID All Rights Reserved

22.

23.

24.

25.

26.

27.

28.

3-2-3. 構築②_Cognito ◼ Cognitoユーザプール設定 ※UI・設定項目は検証当時(2023年)のものユーザプール <userpool_1> リソースサーバ <resoueceserver> カスタムスコープ <resoueceserver>/<customscope> アプリクライアント test-client01 構築①からの変更点 ID 1. IDプロバイダーに「Google」を追加シークレット 2. OAuth2.0許可タイプでアプリクライアント「認証コード付与」を選択 3. OpenID Connectのスコープで ID 「OpenID」を選択(OIDC利用のため) XXXXXXXXXXX YYYYYYYYYYY test-client02 WWWWWWWWWW シークレット VVVVVVVVVV アプリクライアント test-client03 ID SSSSSSSSSS シークレット - 28 Copyright(c)2025 NID All Rights Reserved

29.

3-2-4. 構築②_API Gateway, Lambda ◼ API Gateway, Lambda設定 ※UI・設定項目は検証当時(2023年)のもの /api API名 test-API プロトコル HTTP API ID QQQQQQQQQQ APIエンドポイント https://<API ID>.execute-api.ap-northeast-1.amazonaws.com/api API Gateway XXXXXXXXXXX(test-client01のID) Lambda 構築①からの変更点 1. 認可スコープの設定を追加 29 Copyright(c)2025 NID All Rights Reserved

30.

4. 検証 ◼ 検証項目【検証①】 1. Client Credentials Grantでアクセストークンを取得できること 2. 取得したアクセストークンでリソース(Lambda)へのアクセスができること【検証②】 1. Googleアカウントでのサインインが可能なこと 2. IDトークンとアクセストークンを取得できていること 3. 取得したアクセストークンでリソース(Lambda)へのアクセスができること 30 Copyright(c)2025 NID All Rights Reserved

31.

4-1. 検証① ◼ アクセストークンの取得クライアント認証として Basic認証を使用 “<test-client01のID>/<test-client01のシークレット>” <userpool名> <resoueceserver>/<customscope> grant typeに「client credentials」を指定 31 Copyright(c)2025 NID All Rights Reserved

32.

4-1. 検証① ◼ アクセストークンの取得クライアント認証に失敗した場合、「invalid_client」が返されてトークン取得が行えない。 test-client01のクライアントIDと test-client02のクライアントシークレットでわざと認証失敗させる “<test-client01のID>/<test-client02のシークレット>” <userpool名> <resoueceserver>/<customscope> 32 Copyright(c)2025 NID All Rights Reserved

33.

4-1. 検証① ◼ リソースへのアクセスアクセス成功(有効なアクセストークン) 取得したアクセストークンを「access_token」に代入して渡す <API ID> 「Hello World!」が返ってきているアクセス失敗(無効なアクセストークン) <API ID> アクセス許可がないことがわかる ※アクセストークンがない場合も同じ結果が返される 33 Copyright(c)2025 NID All Rights Reserved

34.

4-1. 検証① ◼ リソースへのアクセス有効なアクセストークンを使用してリソースへアクセスする場合、リクエストボディにトークン取得時と異なるクライアント情報を含めたとしてもリソースへのアクセスは行える。取得したアクセストークンを「access_token」に代入して渡す <API ID> <test-client02のID> 「Hello World!」が返ってきている test-client02(API Gatewayの対象者ではないユーザ)のクライアントIDを含める 34 Copyright(c)2025 NID All Rights Reserved

35.

36.

37.

4-2. 検証② ◼ リソースへのアクセスアクセス成功(有効なアクセストークン) 取得したアクセストークンを「access_token」に代入して渡す <API ID> 「Hello World!」が返ってきているアクセス失敗(無効なアクセストークン) 取得したIDトークンを「id_token」に代入して渡す <API ID> アクセスできない ※アクセスに特定のスコープを必要としており(p.29参照)、 IDトークンはスコープの情報を持たないため Copyright(c)2025 NID All Rights Reserved 37

38.

4-2. 検証② ◼ ユーザ情報の取得(追加検証) ユーザ情報エンドポイントへのリクエスト取得したアクセストークンを「access_token」に代入して渡す ★IDトークンを渡したリクエストはトークン内に「openid」スコープがないため、401が返される。 ※OAuth2.0を使って発行したアクセストークンでも同じように情報の取得はできない。 38 Copyright(c)2025 NID All Rights Reserved

39.

40.

41.

PKCE ◼ PKCE とは認可コード横取り攻撃への対策として利用できる。 Authorization Code Flowにて、認可コード取得・トークン取得の際に以下のパラメータを用いる。 ⁃ code_verifier ⁃ code_challenge ⁃ code_challenge_method 次ページより、Authorization Code Flow + PKCE でのトークン取得までを確認する。 41 Copyright(c)2025 NID All Rights Reserved

42.

PKCE ◼ Googleアカウントによるサインイン & 認可コード取得 Cognitoのログインページ URLに以下のパラメータが追加されている。 - code_challenge_method=S256 - code_challenge=XXXXXXXXXXXXXXXXXXXXXXXXXXX Googleアカウントでサインインする認可コードが取得できる認可コードリダイレクト 42 Copyright(c)2025 NID All Rights Reserved

43.

44.