
Amazon Cognitoを用いた 認証・認可の基本
近年、サイバー攻撃の激化・高度化により、認証・認可の重要性はますます高まっています。そこで、AWSが提供する認証・認可サービス「Amazon Cognito」を用い、基本的な構成の技術検証を実施しました。
本検証は、社内の若手メンバー(1~3年目)が参加し、今後の社内システムやサービス開発における認証・認可技術の基礎固めを目的としています。
※本記事はスライドの記載内容をもとに、検証の要点を簡潔にまとめています。詳細な検証内容や技術的な説明は埋め込みのスライド本文をご参照ください。
検証の目的
- Amazon Cognitoを活用した認証・認可の基礎技術の確認
- OAuth2.0およびOpenID Connect(OIDC)を用いた構成の実装と動作検証
- 外部IDプロバイダー(Google)との連携による認証フローの理解
検証内容
検証①:API Gateway + Amazon Cognito(OAuth2.0 Client Credentials Grant)
- API GatewayとAmazon Cognitoを連携し、サービス間通信(マシン間通信)を想定したClient Credentials Grant方式でアクセストークンを取得
- Lambda関数へのアクセス制御をアクセストークンで実施
- 構成図:API Gateway → Cognito(認可サーバ)→ Lambda(リソースサーバ)

検証②:Amazon Cognito + Google IdP(OIDC Authorization Code Flow)
- Amazon CognitoにGoogle IdP(Google Cloud)を連携し、Googleアカウントによるサインインを実装
- Authorization Code Flowで認可コード・IDトークン・アクセストークンを取得
- Lambda関数へのアクセス制御をアクセストークンで実施
- 構成図:Cognito(IdP)→ Google IdP → API Gateway → Lambda

※構成図や詳細な検証手順はスライド本文をご参照ください
検証結果
検証①:Client Credentials Grant
- クライアント認証(Basic認証)でアクセストークンを取得可能
- 誤ったクライアントID/シークレットでは「invalid_client」エラーとなり、トークン取得不可
- 有効なアクセストークンを用いることで、Lambdaリソースへのアクセスが許可される
- アクセストークンが無効または未付与の場合、リソースアクセスは拒否される
- アクセストークンの有効性のみでアクセス制御が可能なため、サービス間連携に適している
検証②:Authorization Code Flow(Googleアカウント連携)
- Googleアカウントでサインインし、認可コード・IDトークン・アクセストークンを取得
- 有効なアクセストークンでLambdaリソースへのアクセスが可能
- IDトークンのみではアクセス不可(IDトークンはアクセスに必要なスコープの情報を持たないため)
- ユーザ情報エンドポイントへのアクセスは「openid」スコープが必要
- OAuth2.0で発行したアクセストークンでもユーザ情報取得は不可(スコープ要件により)
まとめ
今回の技術検証を通じて、Amazon Cognitoを用いた認証・認可の基本構成を実装し、トークンベースのアクセス制御の有効性を確認しました。今後は、より複雑な認証・認可要件への対応や、他の外部IDプロバイダーとの連携、運用面でのセキュリティ強化など、さらなる技術検証を進めていきます。社内システムやサービス開発において、今回得られた知見を活かし、安全かつ柔軟な認証・認可基盤の構築を目指します。
※本資料に登場する会社名・製品・サービス名、ロゴマークなどは該当する各社の商号・商標または登録商標です。






