【ITニュース解説】Cognito user pool authorizer in API Gateway

システムエンジニアを目指す初心者が、Webサービスやアプリケーションを開発する上で避けて通れないのが「認証」と「認可」というセキュリティの仕組みである。ユーザーが誰であるかを確認し（認証）、そのユーザーが特定のリソースにアクセスする権限があるかを判断する（認可）プロセスは、サービスの安全性を保つために極めて重要だ。この記事では、AWSのAmazon API GatewayとAmazon Cognitoという二つのサービスを連携させ、効率的かつセキュアにAPIの認証・認可を実装する方法について解説する。

Amazon API Gatewayは、Webアプリケーションやモバイルアプリがバックエンドのサービスと通信するための入り口となるサービスだ。ユーザーからのリクエストを受け取り、バックエンドのLambda関数や他のHTTPエンドポイントにルーティングする役割を果たす。このAPI Gatewayの入り口で、不正なアクセスを防ぐための仕組みを設定するのが「オーソライザー（Authorizer）」である。今回焦点を当てるのは、「Cognitoユーザープールオーソライザー」というタイプのオーソライザーだ。

このCognitoユーザープールオーソライザーをAPI Gatewayに設定するということは、API Gatewayに対して、incoming（入ってくる）リクエストの認証にAmazon Cognitoを利用し、各リクエストに含まれるJWT（JSON Web Token）という特殊なチケットをCognitoユーザープールに対して検証し、そのチケットが有効であればリクエストを許可し、無効であれば拒否するように指示していることになる。これは、開発者が自前で複雑な認証ロジックをイチから書く必要なく、APIをセキュアに保護できる非常に強力な方法である。

具体的にどのように動作するのか。まず、ユーザーはAmazon CognitoというAWSの認証サービスを使ってサインインする。例えば、ユーザー名とパスワードを入力してログインするイメージだ。Cognitoは、ユーザーが正しくサインインできたことを確認すると、IDトークンやアクセストークンと呼ばれる特別な「チケット」をユーザーに発行する。このチケットがJWTである。次に、ユーザーのアプリケーション（クライアント）は、API Gatewayを通じてバックエンドのサービスにアクセスしたい場合、このCognitoから受け取ったチケットをHTTPリクエストの「Authorization」ヘッダーという場所に含めてAPI Gatewayに送信する。API Gatewayは、このリクエストを受け取ると、バックエンドのサービス（例えばAWS Lambda関数など）にリクエストを転送する前に、設定されているCognitoユーザープールオーソライザーを使って、チケットが本物で有効なものかどうかをCognitoユーザープールに問い合わせて検証する。チケットが有効であればバックエンドサービスへのアクセスが許可され、無効であればアクセスは拒否される。

この仕組みを実際に実装する手順は以下の通りである。まず、Cognitoユーザープールを作成する。これはユーザーの情報を管理し、サインイン機能を提供する場所だ。サインイン方法（メールアドレスやユーザー名など）を設定し、作成後に表示されるユーザープールIDとアプリクライアントIDを控えておく。次に、API GatewayでAPIを作成する。これはGETやPOSTといったHTTPメソッドを定義し、APIのエンドポイントとなるリソースを設定する作業だ。その後、作成したAPIにCognitoオーソライザーを設定する。API Gatewayの画面で「オーソライザー」を選び、タイプをCognitoに指定し、先に作成したCognitoユーザープールを選択して保存する。最後に、作成したオーソライザーをAPIの各メソッドに紐付ける。特定のGETメソッドやPOSTメソッドに認証が必要な場合、そのメソッドの「メソッドリクエスト」設定で認証にCognitoオーソライザーを指定する。これらの設定が完了したら、APIをデプロイすることで、設定が有効になる。

実際にこのオーソライザーを利用する際には、クライアントはCognitoから取得したIDトークンを「Authorization: <id_token>」という形式でHTTPリクエストヘッダーに含めてAPI Gatewayに送る必要がある。API Gatewayはこのトークンを受け取り、バックエンドにリクエストを転送する前にCognitoに問い合わせてトークンの有効性を検証する。このように、ユーザーがサインインし、トークンを取得し、そのトークンをAPIリクエストに含めてAPI Gatewayに送るという一連の流れが、常にセキュリティチェックを通ることで、APIが保護されるのである。この方法の最大のメリットは、認証に関するカスタムコードを開発者が書く必要がなく、AWSが提供するマネージドサービスを活用することで、高いセキュリティと信頼性を手軽に実現できる点だ。さらに、AWS WAF（Web Application Firewall）と組み合わせることで、DDoS攻撃などのWeb攻撃からAPIをさらに保護するといったベストプラクティスも存在する。

ここからは、この知識を深めるための実践的なシナリオを見ていこう。

最初の質問は、API Gatewayが403エラーを返す場合のトラブルシューティングについてだ。アプリケーションがLambda関数からAPI Gateway APIを呼び出しており、API GatewayはCognitoオーソライザーを使用している。Lambda関数は「ユーザーID」をAuthorizationヘッダーに渡しているが、API Gatewayは403（Forbidden、アクセス拒否）を返す。この問題の解決策は、クライアントのGETリクエストでAuthorizationヘッダーに「有効なトークン」を含めるように修正することだ。403エラーは認証の問題を示しており、CognitoオーソライザーはユーザーIDではなく、Cognitoが発行したJWT形式の有効なトークンを求めている。ユーザーIDをそのまま渡しても認証は成功しないため、正しく認証されたときにCognitoから受け取るIDトークンやアクセストークンをAuthorizationヘッダーに含める必要がある。

二つ目の質問は、あるAWSアカウントのIAMユーザーのみにAPI GatewayのAPIへのアクセスを許可する方法についてである。この要件を満たすには、二つのステップを組み合わせるのが最善だ。一つは、IAMパーミッションポリシーを作成し、それを各IAMユーザーにアタッチすること。そして、APIのメソッド認証タイプを「AWS_IAM」に設定し、APIリクエストをSignature Version 4を使って署名することだ。もう一つは、API Gatewayのリソースポリシーを作成し、特定のIAMユーザーのみにアクセスを許可するように設定することである。API Gatewayの認証方法として「AWS_IAM」を選択すると、IAMユーザーやロールが持つパーミッションに基づいてアクセスが制御される。さらに、リソースポリシーはAPI Gateway自体に適用されるポリシーで、特定のプリンシパル（ここでは他のAWSアカウントのIAMユーザー）からのアクセスを許可または拒否できるため、二重のセキュリティ層として機能する。

三つ目の質問は、API GatewayでRESTサービスを異なるバージョンでテスト運用する最善の方法についてである。これに対する最適なアプローチは、APIバージョンを「ユニークなステージ」としてデプロイし、それぞれにユニークなエンドポイントを持たせ、さらに「ステージ変数」を使って追加のコンテキスト情報を提供することだ。API Gatewayのステージ機能は、開発、テスト、本番といった環境ごとにAPIのバージョンを管理するために設計されている。各ステージは独立したデプロイ環境を提供し、それぞれが固有のURLを持つ。例えば、「/dev」や「/prod」といったパスで異なるバージョンのAPIにアクセスできる。ステージ変数は、ステージ固有の設定値を定義できるため、同じLambda関数でもステージに応じて異なるデータベースを参照させるなど、柔軟な運用が可能になる。これにより、バージョンごとの隔離されたテスト環境が実現し、管理とテストが非常に容易になる。

これらの解説を通じて、Amazon API GatewayとAmazon Cognitoを組み合わせた認証の基本、具体的な実装方法、そして関連する応用的なシナリオについての理解が深まったことだろう。クラウドサービスを活用することで、セキュリティや運用管理の負担を軽減しつつ、堅牢なシステムを構築する力が身につくことを願う。