基于Google API与OAuth2的无状态RESTful API实现问询

方案一：自身令牌+分布式缓存存Google令牌 #

• 调整流程：用户完成OAuth2授权后，你的Node.js服务只签发自己的无状态JWT令牌（带用户标识、过期时间等必要信息），把Google的访问令牌+刷新令牌和用户ID绑定，存到Redis这类支持过期时间的分布式缓存里（过期时间和Google令牌保持一致）。
• 调用逻辑：用户用你的JWT请求API时，先验证这个令牌的有效性；过了验证就根据用户ID从缓存里拿对应的Google访问令牌，去调Google Calendar API。要是令牌过期了，自动用刷新令牌换个新的，更新缓存后再发起请求。
• 好处：不用自己盯两个令牌的过期时间，缓存会自动处理；自身认证令牌和Google的令牌完全分开，符合你不想混用的要求；API的无状态特性也能保留（自身JWT是无状态的，缓存属于外部存储不影响API本身的无状态设计）。

方案二：授权码模式+服务端全权管Google令牌 #

• 调整流程：用户走OAuth2授权码模式，把授权码发给你的服务；你的服务用授权码换Google的访问令牌和刷新令牌后，直接给客户端返回自己签发的JWT，Google的令牌只存在服务端（同样用Redis存）。
• 核心逻辑：客户端全程只拿你的JWT，所有和Google API的交互都由你的服务来做，客户端根本碰不到Google的令牌。
• 好处：彻底杜绝客户端接触Google令牌的风险，安全性更高；服务端统一管Google令牌的刷新和过期，客户端不用操心第三方令牌的逻辑。

方案三：Google ID令牌做身份校验+自身权限令牌 #

• 调整流程：用户完成Google OAuth2登录后，拿到Google ID令牌（这是个已签名的JWT，带用户身份信息），客户端把这个ID令牌发给你的服务；你的服务用Google公钥验证这个ID令牌的有效性，没问题就签发自己的权限令牌（给后续API请求用），同时把Google的访问令牌和用户ID绑定存起来。
• 好处：借Google的ID令牌完成用户身份校验，减少自己开发认证逻辑的工作量；自身权限令牌和Google服务令牌完全分离，满足你的安全需求。

几个关键提醒 #

• 缓存选Redis这类分布式的，多实例部署时令牌能共享，不会出问题。
• 一定要做自动刷新逻辑：当Google访问令牌过期时，服务端自动用刷新令牌换新的，更新缓存，这个过程对客户端完全透明。
• 自身签发的JWT要用强密钥签名，过期时间设合理点；缓存里的Google令牌要加密存，别泄露了。

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