Google API Gateway+Firebase：X-Forwarded-Authorization可否替代推荐的X-Apigateway-Api-Userinfo

使用X-Forwarded-Authorization获取身份的潜在问题 #

• 安全边界的不可靠性
  你依赖的X-Forwarded-Authorization头是API Gateway在转发请求时的默认复制行为，并非强制的可信来源标识。如果你的后端服务存在绕过API Gateway的直接访问入口，攻击者完全可以自行构造带有任意Authorization/X-Forwarded-Authorization头的请求直连后端，触发你代码里的admin.auth().verifyIdToken逻辑完成身份伪造——因为后端本身没有做“该请求必须来自API Gateway”的来源校验，整个认证防线会完全失效。
• 逻辑重复的资源消耗
  API Gateway本身已经完成了Firebase JWT的签名校验、有效期校验、受众校验全流程，你在后端再走一遍verifyIdToken的完整验签逻辑，相当于把网关的认证动作重复执行，高并发场景下会产生不必要的计算开销。
• 行为变更的兼容性风险
  目前API Gateway复制Authorization头到X-Forwarded-Authorization的逻辑，属于网关内部的默认实现细节，并非官方承诺的长期稳定契约。如果后续版本调整转发规则（比如不再透传该头、修改头的字段格式），你的后端代码会直接出现身份校验失效的问题，没有提前适配的缓冲空间。

官方推荐X-Apigateway-Api-Userinfo的深层考量 #

• 可信边界的明确隔离
  X-Apigateway-Api-Userinfo是API Gateway在完成全量身份校验后专门生成的透传头，从设计上就定位为“网关校验完成后的可信结果输出”。后端服务只需要信任这个头的内容，不需要再校验原始Token，从机制上避免了外部请求绕过网关伪造身份的可能——外部攻击者根本不知道该头的格式、生成规则，就算强行构造也无法通过后端的格式校验。
• 最小信息传递的安全设计
  该头仅会透传你在网关配置中明确指定的用户身份字段（比如用户ID、邮箱、租户标识），不会把原始JWT中携带的敏感 claims（比如第三方登录关联的临时授权凭证、权限范围细节）透传到后端，从传递链路层面减少敏感身份信息的泄露风险。
• 长期兼容的稳定性保障
  X-Apigateway-Api-Userinfo头的格式、内容规则是通过官方文档明确对外承诺的稳定契约，后续网关版本迭代不会随意变更该头的行为，后端基于该头开发的逻辑不需要跟随网关版本调整做适配，长期维护成本更低。

补充说明：你之前推断的“X-Apigateway-Api-Userinfo解码后的对象结构与Firebase Auth Admin SDK的DecodedIdToken结构一致”是符合实际实现的，实际开发中只需要对该头做base64url解码即可拿到结构化的用户信息，不需要再重复执行验签逻辑。

// authHeaders = 'Bearer ...'
const authHeaders = headers['X-Forwarded-Authorization'];

const token = authHeaders.split(' ')[1]

const decodedToken = await admin.auth().verifyIdToken(token)

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