ある企業が、API GatewayのHTTP APIとLambda統合でREST APIを構築している。フロントエンドのSPA（React）は認証にAmazon Cognitoを使用しており、CognitoのIDトークンをAuthorizationヘッダーに付与してAPIを呼び出している。APIは段階的に他社向けに開放する予定もあるため、将来的にCognito以外のIDプロバイダー（例: Auth0）にも対応できる設計にしたい。現時点での実装として最も将来的な拡張性が高い認証アーキテクチャはどれか。
- A. API GatewayのHTTP APIにCognito User Pool Authorizerを直接設定し、Lambda関数内でトークンのclaimsを検証する
- B. Cognito Identity Poolを使ってCognitoユーザーをIAMロールに変換し、API GatewayのAWS IAM認証（Sigv4署名）を使う
- C. API Gatewayの前段にAmazon API Gateway v1（REST API）に切り替えて、カスタムLambda Authorizerで全IDPのJWT検証ロジックを一元管理する
- D. API GatewayのHTTP APIにJWTオーソライザーを設定し、CognitoをIssuerとして設定する。将来他のIDPに対応する際はJWTオーソライザーのIssuerを追加するか、Lambda Authorizerに切り替える
解答と解説を見る
正解: D
HTTP APIのJWTオーソライザーはOIDC標準に基づいてIssuer URLとAudienceを設定するだけでJWT検証を行う。Cognitoは標準的なOIDCプロバイダーであるため、現時点ではCognitoのIssuer URLを設定すれば動作し、将来Auth0などの他のOIDC互換IDPに対応する際は、新しいIDPのIssuer URLを追加するか、より複雑な要件であればLambda Authorizerに移行するという段階的な拡張が可能である。JWT標準（RFC 7519）に依存することで特定ベンダーへのロックインを最小化できる。選択肢AのHTTP APIの「Cognito User Pool Authorizer」という設定は存在せず（HTTP APIはJWTオーソライザーのみでCognitoを使う）、Cognito専用の設定ではAuth0への移行時に設定の全面的な見直しが必要になる。選択肢CのREST API v1への切り替えは後退であり、HTTP APIが提供する低レイテンシ・低コストの利点を失う上、Lambda Authorizerへの全面移行という大規模変更を要する。選択肢BのCognito Identity Pool + IAM Sigv4は高いセキュリティを提供するが、クライアント側でSigv4署名を実装する必要があり、他社向け開放時にクライアントの実装負荷が非常に高くなる。
📚 関連サービスの解説: Amazon API Gateway ・ Amazon Cognito