我正在我的 React / Redux（或其他基于 Flux 的状态管理）应用程序中实现 OAuth，而且我正在努力寻找有关各种 access_token 扩展方法的“优缺点”的好信息。
1) 拦截 401 响应
一种选择是拦截 API 请求（例如使用“fetch-intercept”包）并检测任何 401 HTTP 代码响应。
在我们 401 的情况下，我们构建逻辑来检索新的 access_token，然后重放先前的请求。
- 重放可以通过在 401 处理程序中调度一个 INVALID_TOKEN 动作来处理，通过中间件捕获这些，然后在 INVALID_TOKEN 动作发生之前重放该动作。
优点
- 身份验证失败相关操作的完全可见性是可见的（因此我们可以使用时间旅行调试重播与身份验证相关的错误）
2) 在 API 调用时检测过期的 access_token
另一种方法是在发送任何请求时，解码我们的 access_token 并检查我们是否需要尽快刷新它（如果需要，那就这样做）。
同样，某种中间件将是此解决方案的最佳选择。我们可以拦截所有的动作，在调度它之前首先检查我们有一个有效的 access_token。
优点
- 不需要仅仅为了接收 401 响应而访问服务器，我们本可以抢占它
缺点
- 在我们刷新令牌时将请求排队的更复杂的逻辑，然后在正确刷新后最终重放它们
3) 轮询方式
登录后，查看令牌过期还有多长时间并设置超时以在此之前刷新 access_token
优点
- 最简单的选项（尤其是在改造丢失现有请求逻辑的应用程序时）
每种方法的任何其他选项或优缺点都将不胜感激，所以也许我可以在这里为那些刚开始的人创建一个详尽的列表