API Gateway REST API で Lambda オーソライザーを使用するときに「HTTP 403 Forbidden」(HTTP 403 禁止) エラーをトラブルシューティングする方法を教えてください。

所要時間3分
0

AWS Lambda オーソライザーを作成した後で、Amazon API Gateway の REST API を呼び出すと、「403 Forbidden」(403 禁止) エラーが発生します。このエラーのトラブルシューティング方法を教えてください。

簡単な説明

このエラーは、次の場合に発生する場合があります。

API への呼び出しに、トークンやアイデンティティソースがない、あるいは NULL または未検証の場合、「401 Unauthorized」(401 未承認) エラーが表示されます。詳細については、「Lambda オーソライザーの作成後に API Gateway 401 Unauthorized エラーが表示されるのはなぜですか?」を参照してください。

注: この記事では、REST API に設定された Lambda オーソライザーに関連する 403 エラーの対処法のみを記載しています。その他の種類の 403 エラーのトラブルシューティングについては、「API ゲートウェイからの HTTP 403 Forbidden (HTTP 403 禁止) のエラーをトラブルシューティングするにはどうすればよいですか?」を参照してください。

解決方法

エラーの原因を確認する

注:

1.    API Gateway からのレスポンスでエラーメッセージを確認します。次のいずれかのようなエラーメッセージを探します。

明示的に拒否する IAM ポリシードキュメントを返す Lambda オーソライザー関数のエラーメッセージの例

{
    "message": "User is not authorized to access this resource with an explicit deny"
}

暗黙的に拒否する IAM ポリシードキュメントを返す Lambda オーソライザー関数のエラーメッセージの例

{
    "message": "User is not authorized to access this resource"
}

呼び出し元へのアクセスを暗黙的に拒否するリソースポリシーがアタッチされた REST API のエラーメッセージの例

{
    "message": "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn>"
}

呼び出し元へのアクセスを明示的に拒否するリソースポリシーがアタッチされた REST API のエラーメッセージの例

{
    "message": "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny"
}

注: API Gateway API へのアクセスが IAM ポリシーによって制御されている場合の動作の詳細については、「ポリシー評価の結果の表」を参照してください。

2.    CloudWatch で API Gateway の実行ログを表示して、認証ワークフローを確認します。Lambda オーソライザーの出力と、API Gateway のリソースポリシー評価の結果に注目してください。次のいずれかのようなログエラーメッセージが表示されます。

必要なトークンがない場合、またはトークンの検証と一致しない場合のログエラーメッセージの例

Extended Request Id: MY92nHDwwwIdGxzR=
Unauthorized request: <request-id>

注: [Extended Request Id] (拡張されたリクエスト ID) はランダムに生成されます。ログ内の [Extended Request Id] (拡張されたリクエスト ID) の値は異なります。

Lambda オーソライザーがアクセスを拒否するポリシーを返す場合のログエラーメッセージの例

Sending request to https://lambda.<region>.amazonaws.com/2015-03-31/functions/<lambda-authorizer-arn>/invocations
Authorizer result body before parsing:
{
  "principalId": "user",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Deny",
        "Resource": "<resource-arn>"
      }
    ]
  }
}
Using valid authorizer policy for principal: <principal>
Successfully completed authorizer execution
The client is not authorized to perform this operation.

注: 返されるポリシーは、Lambda オーソライザーによって異なります。返されたポリシーの resource-arn に要求元リソースが含まれていない場合、リクエストは暗黙的に拒否されます。

API Gateway リソースポリシーがリクエストを拒否する場合のログエラーメッセージの例

Extended Request Id: MY-BIVb4GEdGeZB=
ExplicitDenyException User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny: <request-id>

Lambda オーソライザーから「not authorized to access this resource」(このリソースにアクセスする権限がありません) エラーを解決する

ポリシーキャッシュが原因で、このリソースへのアクセスが承認されていない旨のエラーが断続的に発生する可能性があります。[Authorization Caching] (認可のキャッシュ) が有効になっていることを確認するために、API Gateway コンソールで Lambda オーソライザーの設定を確認します。その後、次のいずれかを実行します。

  • 1 回限りのテストでは、AWS CLI コマンド flush-stage-authorizers-cache を実行します。オーソライザーのキャッシュエントリがフラッシュされた状態で、再度 API を呼び出します
  • ポリシーのキャッシュをオフにし、再度 API を呼び出します
    注: リクエストパラメータベースのオーソライザーでポリシーのキャッシュをオフにした場合、API Gateway は、Lambda オーソライザー関数を呼び出す前に API の呼び出しを検証しません。
  • [Token Source] (トークンソース) (トークンベースのオーソライザーの場合) 、または [Identity Sources] (アイデンティティソース) (リクエストパラメータベースのオーソライザーの場合) で指定されたヘッダー名を更新して、オーソライザーのキャッシュキーを変更します。API を再デプロイして変更を適用します。その後、新しく設定したトークンヘッダーまたはアイデンティティソースを使用して、再度 API を呼び出します

エラーが一貫して表示される場合は、Lambda オーソライザー関数のコードを確認して、オーソライザーが呼び出し元へのアクセスを明示的に拒否する理由を特定します。問題の原因がキャッシュにあると判断した場合は、呼び出し元にアクセスできるようにコードを更新できます。手順については、「キャッシュが有効になっている Lambda オーソライザーを使用する API Gateway プロキシリソースが、HTTP 403 エラーを返すのはなぜですか」を参照してください。

「not authorized to perform: execute-api:Invoke」(実行権限がありません: execute-api:Invoke) エラーを解決する

API のリソースポリシーを確認して、API リソースポリシーが有効でないかどうか、呼び出しへのアクセスを明示的に拒否しているかどうかを確認します。API の実行ログを表示することで、リソースポリシーのレスポンスの内容を確認できます。

詳細については、「Amazon API Gateway のアクセスポリシー言語の概要」、および「Lambda オーソライザーとリソースポリシー」を参照してください。


関連情報

API Gateway Lambda オーソライザーの使用

再デプロイを必要とする REST API の更新

API Gateway での REST API へのアクセスの制御と管理

コメントはありません

関連するコンテンツ