OAuth2 authorization code flow模式下生成的authorization code应存储在何处？

授权码是授权码流中的一次性、短有效期凭证，存储方案需要匹配该特性，同时覆盖兑换阶段的所有校验需求。你生成授权码时，需要同步关联存储的核心校验字段包括：授权码值、对应客户端ID、授权用户ID、申请的权限范围（scope）、授权时传入的重定向URI、过期时间、是否已被兑换的标记。

从概念层面，可选的存储方案分为两类：

1. 服务端中心化存储 #

这是绝大多数生产场景的首选方案，逻辑简单、安全边界清晰：

• 优先选用KV类缓存中间件（如Redis、Memcached），天然适配授权码短有效期、高频读写、自动过期的特性：
  • 以授权码值为Key，关联的所有校验字段为Value存入缓存，直接设置缓存过期时间等于授权码有效期（OAuth2规范推荐最长不超过10分钟）
  • 客户端发起兑换请求时，直接用请求携带的授权码查缓存：Key不存在直接返回无效；Key存在的话校验客户端ID、重定向URI和授权申请阶段的传入值一致，确认未被兑换后，立即删除该Key，保证授权码只能被使用一次，避免重放攻击
• 若没有独立缓存组件，也可以存储在授权服务器的本地关系型数据库中，需要单独建立授权码表，加过期时间索引，定期清理过期数据，仅适合低流量场景使用。

2. 自包含授权码（无服务端存储方案） #

如果你不想维护额外的存储，也可以把所有校验信息直接编码到授权码本身，实现无状态校验：

• 生成授权码时，将所有需要校验的字段用仅授权服务器持有、不对外泄露的对称加密密钥（如AES）加密后，再做Base64编码，生成最终返回给客户端的授权码
• 兑换时直接对授权码做解密，解析出内部的字段做有效性校验，不需要查询任何服务端存储
• 注意该方案需要额外补充一次性校验逻辑：可以在加密字段中加入唯一随机串，同时维护一个最近10分钟内已兑换授权码的唯一串黑名单，兑换成功就将对应唯一串加入黑名单，黑名单的过期时间和授权码有效期一致，避免同一授权码被多次兑换。

不管选用哪种存储方案，兑换阶段必须同时满足四个校验条件才允许下发access token：授权码未过期、客户端ID与授权申请阶段一致、重定向URI与授权申请阶段一致、授权码未被使用过。

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