API Gatewayの認証、既製品か自作かで迷った話

おはようございます、YASUです。

前回LambdaのIAM権限を整理しましたが、実際にAPIを外部に公開する場面では、もう一段別の「認証・認可」という壁が出てきます。今日はAPI Gatewayの認証まわり、特にCognitoオーソライザーとLambdaオーソライザーの違いを整理します。

結論

API Gatewayの認証には、大きく分けて「Cognitoオーソライザー(既製品)」と「Lambdaオーソライザー(自作)」の2種類があります。どちらも「トークンが正しいユーザーのものか確認してから、リクエストを通す」という役割は同じですが、検証のロジックをAWS側に任せるか、自分でコードを書くかという点が根本的に違いました。

そもそも、なぜAPI Gatewayに認証が必要なのか

これまで扱ってきたLambdaの実行ロールは、「Lambda関数自身が、他のAWSサービスに対して何をしていいか」を決めるものでした。しかしAPI Gatewayを経由してインターネットに公開したAPIの場合、それとは別に「そもそも、このリクエストを送ってきたのは誰なのか」を確認する必要があります。これが認証・認可の役割です。

方式1:Cognitoオーソライザー

Amazon Cognitoは、ユーザー登録・ログイン機能をまるごと提供してくれるサービスです。API GatewayにCognitoオーソライザーを設定しておくと、リクエストに含まれるトークンが有効かどうかを、API Gateway自身がCognitoに問い合わせて自動的に検証してくれます。

1. ユーザーがCognitoにログインし、IDトークンを取得する
2. そのトークンを付けてAPI Gatewayにリクエストを送る
3. API GatewayがCognitoにトークンの正当性を確認する
4. トークンが有効 → Lambdaにリクエストを転送
   トークンが無効 → 401 Unauthorizedを返す

この方式の良いところは、認証ロジックを自分で書く必要がないことです。ユーザー管理からトークンの検証まで、Cognitoという既製品にほぼ任せられます。

方式2:Lambdaオーソライザー

一方Lambdaオーソライザーは、「認証の判断ロジックを、自分でLambda関数として実装する」方式です。リクエストが来るたびに、専用のLambda関数(オーソライザー)が呼び出され、そのコードの中で「このリクエストを通していいか」を判定します。

1. リクエストが届く
2. API Gatewayが、認証用のLambda関数(オーソライザー)を呼び出す
3. オーソライザーが、独自のロジックでトークンやAPIキーを検証する
   (例:自社のデータベースと照合する、JWTのクレームを独自に解析するなど)
4. 検証結果に応じて、リクエストを通すかどうかが決まる

Cognitoのような既製品では対応できない、独自の認証要件(例えば、外部のIDプロバイダーと連携する、複数のユーザープールを横断して検証したいなど)がある場合、この方式が選ばれるようです。

使い分けの判断軸

「まず既製品(Cognito)で足りるか検討し、足りない場合だけ自作(Lambda)に踏み込む」という考え方は、以前紹介したモジュール化の話(車輪の再発明を避ける)とも通じる発想だと感じました。

試験で問われそうなポイント

調べていて、この分野は「認証が成功した後、Lambda側にどんな情報が渡されるか」も問われやすいと感じました。Cognitoオーソライザーの場合、認証されたユーザーの情報(ユーザーID、メールアドレス、所属グループなど)が、そのままLambda関数に渡されます。つまりLambda側では「誰が呼び出したか」をあらためて問い合わせる必要がなく、渡された情報をそのまま使って処理を進められる、という設計になっています。

実務でよくある事故のパターン

調べる中で見かけたのが、「オーソライザーはメソッドごとに設定する必要がある」という注意点でした。API Gatewayでは、APIの入り口(リソース)ごとに複数のメソッド(GET、POSTなど)を作れますが、オーソライザーを設定し忘れたメソッドがあると、そこだけ認証が素通りしてしまう、という事故につながります。以前紹介した「うっかりミスは、個人の注意力ではなく仕組みで防ぐ」という考え方は、ここにもそのまま当てはまりそうです。

まとめ

LambdaのIAM権限に続いて、API Gatewayの認証まわりも整理できたので、少しずつDVAの全体像が繋がってきた感覚があります。それでは、また明日!