API Gateway绑定Auth Lambda后授权异常及日志缺失问题排查

Let's break down what's going wrong here and fix it step by step:

Root Causes of Your Issues #

1. Incomplete Custom Authorizer Configuration #

Your SAM template's MyAuthorizer is missing two critical settings:

• Type: While TOKEN is the default type for Lambda authorizers, explicitly defining it avoids ambiguity.
• IdentitySource: API Gateway needs to know where to extract the authorization token from the request. Without this, the authorizer won't trigger correctly—this explains why your unauthenticated request went straight through to the Greeting Lambda with no Auth logs.

2. Invalid Auth Lambda Response Format #

Your Auth Lambda returns a generic API response ({ statusCode: 200, body: ... }), but API Gateway requires a specific IAM policy structure to evaluate authorization. If the response doesn't match this format, API Gateway either skips the authorizer entirely or returns an unauthorized status without logging the Lambda execution.

3. Incorrect Request Header Format #

You're sending the entire authorization event object in the request header, but TOKEN-type authorizers only expect the raw token value in a designated header (like Authorization). API Gateway automatically constructs the full event (including authorizationToken and methodArn) and passes it to your Auth Lambda—you don't need to send this manually.

Step-by-Step Fixes #

1. Update CloudFormation Template for the Authorizer #

Modify the GreetingsApiGateway resource to include the missing authorizer configuration:

GreetingsApiGateway:
  Type: AWS::Serverless::Api
  Properties:
    StageName: Prod
    Auth:
      DefaultAuthorizer: MyAuthorizer
      Authorizers:
        MyAuthorizer:
          Type: TOKEN
          FunctionArn: !GetAtt AuthLambda.Arn
          IdentitySource: method.request.header.Authorization  # Tell API Gateway where to find the token

2. Fix the Auth Lambda Response Format #

Rewrite your Auth Lambda to return the required IAM policy structure. Here's a working example with debug logging:

exports.auth = async (event) => {
  console.log("Auth Lambda triggered with event:", JSON.stringify(event)); // Log for debugging

  // Extract token from the event (API Gateway populates this automatically)
  const token = event.authorizationToken;
  const methodArn = event.methodArn;

  // Example authorization logic: Replace with your actual validation
  const isAuthorized = token === "my-valid-token";
  const effect = isAuthorized ? "Allow" : "Deny";

  // Return the required policy document
  return {
    principalId: "user-123", // Any unique identifier for the user
    policyDocument: {
      Version: "2012-10-17",
      Statement: [
        {
          Action: "execute-api:Invoke",
          Effect: effect,
          Resource: methodArn
        }
      ]
    }
  };
};

3. Send Requests Correctly #

In Postman, send your GET request to /hello with a single header:

• Header Key: Authorization
• Header Value: my-valid-token (or whatever valid token you define in your Auth Lambda logic)

Expected Results After Fixes #

• No Authorization header: Auth Lambda triggers, returns a Deny policy, request is rejected, and you'll see logs in CloudWatch.
• Valid token in header: Auth Lambda triggers, returns an Allow policy, request succeeds with "Hello Beautiful World!", and logs appear in CloudWatch.
• Invalid token in header: Auth Lambda triggers, returns a Deny policy, request is rejected, and logs are visible.

Also, a quick note: nodejs8.10 is end-of-life and no longer supported. Consider upgrading to a newer runtime like nodejs18.x to avoid security risks and compatibility issues.

内容的提问来源于stack exchange，提问作者Igor L.