AWS Cognito：访问令牌与身份令牌的区别及替换可行性咨询

这是个非常典型的OIDC入门困惑，我来帮你拆解清楚两者的定位、适用场景，以及为什么不能混用：

为什么不能用Identity Token替代Access Token？ #

虽然你现在的验证逻辑只用到了sub字段，看起来暂时能跑，但这里藏着不少隐患：

• 受众不匹配：Identity Token的aud（受众）字段指向的是你的前端客户端，而Access Token的aud是你的后端API。如果后续你的API升级验证逻辑（比如加入aud校验、权限scope校验），用Identity Token请求就会直接失败。
• 安全风险更高：Identity Token里塞满了用户的身份细节——email、name、自定义属性这些都是敏感数据，把它放在浏览器里随AJAX请求传输，等于把用户信息暴露在前端，一旦XSS攻击发生，这些数据很容易被窃取。Access Token的设计就是轻量化，只带必要的身份标识和权限信息，安全性更高。
• 违反协议规范：OIDC协议明确划分了两种令牌的职责，混用会让你的认证流程脱离标准，后续对接第三方服务、升级身份系统时会遇到各种兼容性问题。

为什么要同时存在这两种令牌？ #

这其实是OIDC把「身份证明」和「资源授权」拆分开的设计智慧：

• Identity Token（身份令牌）：是给前端客户端用的，核心作用是「证明用户是谁」。前端拿到它后，可以解析出用户的基本信息、自定义属性，用来做页面个性化展示（比如显示用户名、头像），或者判断用户是否已登录。
• Access Token（访问令牌）：是给后端API用的，核心作用是「授权访问资源」。后端通过验证它来确认请求者有资格访问特定API，它不需要包含用户的所有身份信息，只需要足够的标识（比如sub）和权限范围（比如scope=read:data）就够了。

针对你当前场景的正确做法 #

如果你的前端需要获取用户的自定义属性（比如custom:blah），正确的流程应该是：

• 在登录流程中，同时获取Identity Token和Access Token（OIDC授权码流本来就会返回这两个令牌）
• 前端用Identity Token解析用户的身份信息，用于页面展示、个性化逻辑
• 前端用Access Token发起AJAX请求到后端API，后端验证Access Token的有效性（签名、aud、exp等），再通过sub获取用户数据

这样既符合标准流程，又兼顾了安全和扩展性。

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