如何在AWS API Gateway中通过映射模板将认证API响应设为其他API请求头？

针对你提到的双微服务场景，我假设你是在支持映射模板的API网关（比如AWS API Gateway这类工具）中实现需求，以下是具体落地步骤：

1. 处理认证服务登录接口的集成与密钥提取 #

先把认证服务的登录API接入网关，在登录请求的响应阶段提取密钥并存入网关上下文：

• 创建网关资源（比如POST /auth/login），指向认证服务的登录接口地址
• 在集成响应中添加映射模板（以AWS网关常用的Velocity语法为例），解析登录返回的JSON数据，将密钥存入网关请求上下文变量：

# 假设登录接口返回格式为 {"access_key": "abc123", "secret_key": "xyz789"}
#set($context.requestOverride.header.X-Access-Key = $input.path('$.access_key'))
#set($context.requestOverride.header.X-Secret-Key = $input.path('$.secret_key'))

如果需要让密钥在用户后续多次请求中生效，建议将密钥存入客户端Cookie（在响应头设置Set-Cookie），或用OAuth2/JWT令牌替代明文密钥，提升安全性。

2. 配置业务服务API的请求映射模板 #

在业务服务的网关集成中，将提取到的密钥注入请求头：

• 创建业务服务的网关资源（比如POST /business/process），指向业务服务的接口地址
• 在集成请求的映射模板中，从上下文或Cookie中取出密钥，添加到业务服务的请求头：

场景一：单次请求链（登录后立刻调用业务API） #

# 从上下文取出之前存储的密钥，注入到业务请求头
#set($context.requestOverride.header.X-Access-Key = $context.requestOverride.header.X-Access-Key)
#set($context.requestOverride.header.X-Secret-Key = $context.requestOverride.header.X-Secret-Key)

# 保留原请求的JSON体内容
$input.json('$')

场景二：会话级复用（用户登录后多次调用业务API） #

如果密钥存在Cookie中，模板可这样编写：

# 从Cookie中提取access_key
#set($cookieStr = $input.params().header.get('Cookie'))
#if($cookieStr && $cookieStr.contains('access_key='))
    #set($accessKey = $cookieStr.split('access_key=')[1].split(';')[0])
    #set($context.requestOverride.header.X-Access-Key = $accessKey)
#end

# 同理提取secret_key
#if($cookieStr && $cookieStr.contains('secret_key='))
    #set($secretKey = $cookieStr.split('secret_key=')[1].split(';')[0])
    #set($context.requestOverride.header.X-Secret-Key = $secretKey)
#end

$input.json('$')

3. 验证与调试 #

• 调用登录API，通过网关测试功能确认响应是否正确设置了上下文变量或Cookie
• 调用业务API，检查网关转发给业务服务的请求头是否包含注入的密钥
• 若模板语法报错，需根据实际使用的网关工具调整语法（比如Spring Cloud Gateway使用SpEL，语法规则不同）

关键注意事项 #

• 敏感密钥必须通过HTTPS传输，避免明文泄露
• 优先使用JWT等令牌替代明文密钥，减少敏感信息直接暴露的风险
• 不同网关的映射模板语法差异较大，需匹配对应工具的规则调整代码

内容的提问来源于stack exchange，提问作者Adnan Roy