本文档旨在指导开发者如何在基于AWS API Gateway和Lambda的REST API中实现基于Bearer Token的身份验证。我们将介绍三种不同的实现方式：使用代理集成、自定义集成以及Lambda Authorizer。通过详细的步骤和代码示例，帮助你选择最适合你的应用场景的方案，并确保API的安全性和可靠性。
在构建REST API时，身份验证是至关重要的一环。本文将探讨如何在AWS API Gateway和Lambda架构下，通过Bearer Token进行身份验证。我们将介绍三种不同的方法，并分析它们的优缺点，以便您选择最适合您需求的方案。
1. 使用代理集成 (Proxy Integration)
代理集成是最简单的入门方式。在这种模式下，Lambda函数负责处理整个HTTP请求和响应的生命周期。API Gateway会将完整的请求信息（包括headers）传递给Lambda函数。
优点：
- 易于实现，上手快。
- 适用于Lambda函数需要完全控制HTTP交互的场景。
缺点：
- Lambda函数需要处理HTTP协议的细节，增加了代码的复杂性。
- 业务逻辑与HTTP处理逻辑耦合在一起。
实现步骤：
- 在API Gateway中，选择“集成类型”为“Lambda 函数代理”。
- 在Lambda函数中，从event.headers字典中读取Authorization header。
- 验证Bearer Token的有效性。
- 根据验证结果返回相应的HTTP状态码和响应。
代码示例 (Python):
def lambda_handler(event, context):
authorization_header = event.get('headers', {}).get('Authorization')
if not authorization_header or not authorization_header.startswith('Bearer '):
return {
'statusCode': 401,
'body': 'Unauthorized'
}
token = authorization_header.split(' ')[1]
# 在这里验证token的有效性 (例如，查询数据库，调用认证服务)
if not validate_token(token):
return {
'statusCode': 403,
'body': 'Forbidden'
}
return {
'statusCode': 200,
'body': 'Hello World!'
}
def validate_token(token):
# 实际的token验证逻辑
# 可以调用外部服务，或者查询数据库
# 返回 True 如果 token 有效，否则返回 False
# 这只是一个示例，需要根据你的实际认证机制进行修改
return token == "valid_token"注意事项：
- event.headers 中的 header 名称是不区分大小写的。
- 确保 validate_token 函数实现了正确的 token 验证逻辑。
2. 使用自定义集成 (Custom Integration) 和请求映射模板
自定义集成允许您更精细地控制API Gateway如何将请求转换为Lambda函数的输入。您可以使用请求映射模板提取header信息，并将其作为JSON对象传递给Lambda函数。
优点：
- 将业务逻辑与HTTP处理逻辑分离。
- 可以定义Lambda函数的输入结构，使其更易于使用。
缺点：
- 需要编写请求映射模板，增加了一定的复杂性。
实现步骤：
- 在API Gateway中，选择“集成类型”为“Lambda 函数”。
- 创建请求映射模板 (Request Mapping Template)，例如使用 application/json 类型。
- 在模板中使用Velocity Template Language (VTL) 提取Authorization header的值，并将其放入JSON对象中。
- 在Lambda函数中，从event对象中读取提取的token值。
- 验证Bearer Token的有效性。
- 根据验证结果返回相应的HTTP状态码和响应。
请求映射模板示例：
{
"token": "$input.params('Authorization').substring(7)"
}代码示例 (Python):
def lambda_handler(event, context):
token = event.get('token')
if not token:
return {
'statusCode': 401,
'body': 'Unauthorized'
}
# 在这里验证token的有效性 (例如，查询数据库，调用认证服务)
if not validate_token(token):
return {
'statusCode': 403,
'body': 'Forbidden'
}
return {
'statusCode': 200,
'body': 'Hello World!'
}
def validate_token(token):
# 实际的token验证逻辑
# 可以调用外部服务，或者查询数据库
# 返回 True 如果 token 有效，否则返回 False
# 这只是一个示例，需要根据你的实际认证机制进行修改
return token == "valid_token"注意事项：
- $input.params('Authorization') 获取的是完整的 Authorization header，需要使用 substring(7) 截取掉 "Bearer " 前缀。
- 请求映射模板需要仔细编写，确保正确提取header信息。
3. 使用Lambda Authorizer (Lambda Authorizer)
Lambda Authorizer（也称为自定义授权方）是一种更高级的身份验证机制。它允许您创建一个专门的Lambda函数来验证请求的身份。API Gateway会在调用您的业务逻辑Lambda函数之前，先调用Authorizer函数。
优点：
- 将身份验证逻辑与业务逻辑完全分离。
- 可以实现更复杂的身份验证机制，例如基于角色的访问控制。
- 可以缓存授权结果，提高性能。
缺点：
- 配置和管理较为复杂。
- 需要编写额外的Lambda函数。
实现步骤：
- 创建一个Lambda Authorizer函数。该函数接收包含Authorization header的event对象，并返回一个IAM策略，指示API Gateway是否允许该请求。
- 在API Gateway中，配置Authorizer。
- 将Authorizer与您的API方法关联。
Lambda Authorizer 函数示例 (Python):
import json
def lambda_handler(event, context):
token = event.get('authorizationToken')
if not token:
return generate_policy('user', 'Deny', event['methodArn'])
# 在这里验证token的有效性 (例如，查询数据库，调用认证服务)
if not validate_token(token):
return generate_policy('user', 'Deny', event['methodArn'])
# 如果token有效，则返回允许访问的策略
return generate_policy('user', 'Allow', event['methodArn'])
def validate_token(token):
# 实际的token验证逻辑
# 可以调用外部服务，或者查询数据库
# 返回 True 如果 token 有效，否则返回 False
# 这只是一个示例，需要根据你的实际认证机制进行修改
return token == "valid_token"
def generate_policy(principal_id, effect, resource):
auth_response = {
"principalId": principal_id,
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": effect,
"Resource": resource
}
]
}
}
return auth_response注意事项：
- Authorizer函数必须返回一个包含IAM策略的JSON对象。
- IAM策略必须指定允许或拒绝访问的资源 (resource)。
- 可以配置Authorizer的缓存时间 (TTL)，以提高性能。
- 如果使用AWS Cognito User Pools，可以直接将其配置为API Gateway的Authorizer，无需编写自定义Lambda函数。
总结：
本文介绍了三种在AWS API Gateway和Lambda架构下实现基于Bearer Token身份验证的方法。选择哪种方法取决于您的具体需求和项目的复杂程度。
- 代理集成 适合快速入门和简单的API。
- 自定义集成 提供了更好的控制和分离，适合中等复杂度的API。
- Lambda Authorizer 是最灵活和安全的方案，适合复杂的API和需要精细访问控制的场景。
无论您选择哪种方法，都请务必确保您的token验证逻辑安全可靠，并遵循最佳安全实践。
