授权码换取token应在客户端还是服务端完成？AWS Cognito相关疑问

问题1：授权码兑换token的操作应当在前端还是后端完成？ #

结合你使用的AWS Serverless架构，可匹配两种场景的最佳实践：

• 纯静态SPA场景（前端部署在S3，无独立后端服务层）：可以直接用AWS Amplify前端SDK在JS侧完成兑换，AWS Cognito的oauth2/token端点默认支持跨域请求，是无后端Serverless场景的标准实现方式。
• 存在BFF层场景（通过API Gateway + Lambda做服务中转）：最佳实践是将兑换操作放在后端完成，兑换后把access_token、id_token通过HttpOnly、Secure、SameSite=Strict属性的Cookie返回给前端，避免前端JS直接接触敏感凭证，大幅降低XSS攻击风险。

问题2：授权码流比隐式流安全的逻辑，和前端需要存储token的矛盾怎么理解？ #

你提到的“用户不会接触到token”是授权码流针对兑换环节的设计优势，和前端存储token的场景并不冲突：

• 隐式流是直接把token放在回调URL的hash段返回，整个传输过程中token会暴露在浏览器历史、网络访问日志里，窃取门槛极低；
• 授权码流的回调环节仅返回一次性授权码，就算授权码泄露，没有Cognito配置的客户端密钥（公开客户端场景为PKCE校验值）也无法兑换token，token是在后端/前端SDK的后台请求中返回，不会出现在URL、浏览器历史记录中。
  至于前端存储token的风险是所有前端会话的共性问题，你可以通过缩短access_token有效期、敏感操作二次校验等方式降低风险，并不影响授权码流本身的安全性优势。

问题3：刷新token的操作应当在前端还是后端完成，refresh token需要存在后端吗？ #

同样可以匹配你使用的Serverless架构选择实现方案：

• 纯SPA前端场景：使用Amplify SDK时refresh token会默认存储在浏览器的localStorage或IndexedDB中，刷新操作由SDK自动完成，不需要后端介入，做好前端XSS防护即可满足普通场景的安全要求。
• 存在BFF层的生产场景：refresh token必须存储在后端，你可以将refresh token存在DynamoDB中，和前端的会话Cookie做映射，access_token过期时前端发起刷新请求到后端Lambda，后端用存储的refresh token向Cognito兑换新的凭证再返回给前端，这种方式完全避免refresh token暴露在前端，是生产环境的最佳实践。
  注意AWS Cognito的refresh token默认有效期最长可设置为10年，一旦泄露风险极高，生产环境如果有条件优先选择后端存储+后端刷新的方案。

问题4：授权码兑换完成后还有用吗，能不能直接丢弃？ #

授权码是一次性时效凭证，AWS Cognito的授权码默认有效期为5分钟，且完成一次token兑换后会立即失效，就算后续有人获取到已经使用过的授权码也无法兑换任何凭证，兑换完成后你可以直接丢弃授权码，不需要做任何存储。

内容的提问来源于stack exchange，提问作者Luka Klarić