如何实现AWS Cognito Hosted UI中redirect_uri的身份认证

核心结论 #

没有办法通过Cognito的原生配置，让Hosted UI在执行302重定向时，直接把id_token作为Authorization请求头发送到你配置的https://example.com/redirect_endpoint，这个限制是浏览器安全规则和OIDC协议设计共同决定的，不是Cognito的功能缺陷。

为什么原生无法实现 #

• Cognito Hosted UI完成认证流程后的重定向，本质是浏览器侧执行的标准跳转动作，授权服务器本身没有权限自定义这个跳转请求的HTTP请求头——所有浏览器发起的跳转请求，请求头仅包含浏览器默认生成的内容，任何第三方服务都无法给这类跳转请求动态追加自定义的头信息。
• 按照OIDC协议的标准设计，Cognito完成认证后返回的id_token、access_token等敏感凭证，只会通过重定向URL的查询参数、URL fragment（也就是#号后面的片段）传递，从来不会通过HTTP请求头携带。

适配鉴权端点的可落地方案 #

针对你当前需要身份校验的https://example.com/redirect_endpoint，只要调整重定向链路，就能完全满足端点的鉴权要求：

• 采用标准的OIDC回调拆分流程：
  • 在Cognito的应用客户端配置中，把一个公开可访问、无需鉴权的轻量前端页面（比如https://example.com/cognito-callback）设置为正式的重定向URI
  • 这个回调页面加载后，通过前端JS逻辑，从URL的fragment或查询参数中提取Cognito返回的id_token
  • 回调页面再通过JS发起对原/redirect_endpoint的接口调用，手动将提取到的id_token拼装为Authorization: Bearer <id_token>格式的请求头，发起请求即可顺利通过端点的身份校验
• 仅适合调试场景的临时方案：
  如果只是临时测试，可以调整鉴权端点的逻辑，允许从URL查询参数中读取id_token完成校验，校验通过后立刻通过302跳转把敏感参数从URL中移除。但这种方式会导致令牌残留在浏览器历史、服务器访问日志中，存在严重的信息泄露风险，绝对不要在生产环境使用。

补充提醒：如果你当前用的是授权码模式（即response_type=code），Cognito在重定向时只会返回临时授权码，根本不会直接返回id_token，这种场景下更需要通过服务端调用Cognito的令牌接口交换获取id_token，也不可能在初始重定向时直接携带令牌请求头。

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