Cloud Endpoints为何推荐用X-Endpoint-API-UserInfo头替代Authorization头？

ESP会将认证结果通过X-Endpoint-API-UserInfo头发送给后端API，推荐使用该头而非原始的Authorization头。

不推荐使用Authorization头的核心原因及安全隐患如下： #

• 原始凭证泄露风险高：Authorization头存储的是未经处理的原始认证凭证，如Bearer JWT、服务账号签名token等，这类凭证可直接用于访问所有绑定对应认证规则的云服务。如果后端代码存在打印头信息日志、内部服务转发未脱敏、存储流程泄露等问题，攻击者拿到有效token后可直接越权访问资源。而X-Endpoint-API-UserInfo是ESP完成认证校验后，仅提取的非敏感身份字段（如账号ID、邮箱、权限范围等），即使泄露也无法直接用于访问其他服务。
• 自行校验易出现安全漏洞：ESP注入X-Endpoint-API-UserInfo之前，已经完成了所有标准认证校验：包括token签名有效性校验、过期时间校验、签发者合法性校验、权限匹配校验等。如果自行解析Authorization头，很容易出现签名校验遗漏、过期时间不校验、签发者白名单配置错误等问题，攻击者可通过构造伪造token直接绕过认证逻辑。
• 无法防范绕过ESP的直接攻击：如果后端服务未配置仅允许ESP访问的网络规则，攻击者可直接绕过ESP向后端传入伪造的Authorization头，后端直接使用该头会完全跳过认证层。而X-Endpoint-API-UserInfo默认只会由ESP注入，客户端传入的同名字段会被ESP自动清理，只要拿到该字段就说明请求已经过ESP的认证校验，不存在伪造风险。
• 多认证方式兼容成本高：如果业务后续需要接入多种认证方式（如用户OIDC登录、服务账号认证、API密钥认证等），不同认证方式的Authorization头格式、解析逻辑完全不同，自行处理需要适配多套逻辑，容易出现兼容漏洞。而X-Endpoint-API-UserInfo会被ESP统一格式化为标准JSON结构，无论前端用哪种认证方式，后端都可以用同一套逻辑解析。

无法接收X-Endpoint-API-UserInfo头的排查方向： #

• 检查OpenAPI文档中对应访问端点是否配置了正确的认证规则，未绑定认证规则的端点ESP不会注入该头
• 确认ESP版本配置未添加过滤X-Endpoint-API-UserInfo的头删除规则
• 确认请求携带的token合法、权限匹配，认证不通过的请求ESP会直接返回错误，不会转发到后端也不会注入对应头

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