基于OIDC与OAuth的认证授权流程及JWT静默刷新疑问

一、redirect_uri的两种配置方案及选择 #

方案1：redirect_uri设为后端回调地址 #

这是更安全的常规做法：

• 用户输入凭证后，授权服务器重定向到后端回调接口，后端在这里完成所有核心验证：校验state防CSRF、校验nonce防重放、验证授权码的合法性、拉取用户信息等。
• 验证通过后，后端再生成自己的会话凭证（比如你现在用的JWT），然后重定向到前端页面，把JWT通过URL参数、Cookie（HttpOnly+Secure）或者前端可接收的方式传递过去。
• 优势：所有敏感的OAuth/OIDC参数（授权码、access token、refresh token）都不会经过前端，避免前端泄露风险。

方案2：redirect_uri直接设为前端地址 #

这种方式适合纯前端应用（SPA），但风险更高：

• 授权服务器直接把授权码、state、nonce等参数返回给前端，前端再把授权码传给后端去兑换token。
• 缺点：前端会接触到授权码，虽然授权码本身有效期短，但如果被截胡还是有被盗用的可能；另外前端需要处理state和nonce的校验逻辑，增加了前端的复杂度和安全风险。

结论：如果你的架构有后端，优先选方案1，把敏感逻辑放在后端处理。

二、基于refresh token实现JWT静默刷新的方案 #

你现在的情况是后端持有refresh token和access token，前端只有自定义JWT，要实现静默刷新可以这么做：

1. 前端监听JWT有效期：前端在每次请求前检查自定义JWT的过期时间，比如提前5分钟触发刷新请求。
2. 后端提供刷新接口：前端向后端发送刷新请求（可以携带当前即将过期的JWT，或者后端通过会话关联用户），后端用持有的refresh token向授权服务器请求新的access token和新的refresh token（如果授权服务器支持滚动刷新）。
3. 后端生成新的自定义JWT：拿到新的access token后，后端重新签名生成有效期内的自定义JWT，返回给前端。
4. 更新前端凭证：前端替换掉旧的JWT，继续正常请求，整个过程用户无感知。

注意点：

• 后端要妥善存储refresh token，最好存在数据库，关联用户ID，并且设置过期时间；每次刷新后如果拿到新的refresh token，要更新存储的旧值。
• 刷新接口要做限流，防止恶意请求；同时可以校验前端的请求来源，增加安全性。

三、当前方案的缺陷 #

1. refresh token管理风险：如果后端没有对refresh token做持久化和过期管理，一旦refresh token泄露，攻击者可以无限刷新获取新的access token和自定义JWT，直到refresh token过期。
2. 自定义JWT与授权服务器凭证的一致性问题：你自己签名的JWT和授权服务器的access token是两套凭证，后端需要同步两者的有效期逻辑，比如如果授权服务器的access token过期了，即使自定义JWT还没过期，后端调用资源服务器时也会失败，这时候需要额外处理这种不一致情况。
3. 缺少主动触发静默刷新的逻辑：如果前端没有提前监听JWT过期，等到JWT过期后再发起请求，会出现请求失败的情况，影响用户体验。
4. 自定义JWT无法主动失效：如果用户注销或者权限变更，后端的自定义JWT无法主动失效，只能等到过期，除非你实现了JWT黑名单机制，但黑名单会增加后端的存储和校验成本。

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