请求第三方 Token，如何保证每次使用的 Token 有效？

[icelo]

现在有一个需求如下：

需要请求第三方的 API 去获取一个 Token，但是这个 Token 会失效，失效时间未知。在其他业务上需要请求第三方接口需要携带上这个 Token，现在需要保证请求第三方接口时，这个 Token 是有效的。

• 方案一：

每次在请求之前都会更新这个 Token： 问题：1 、会存在并发问题（虽然说这个 token 被修改没影响）； 2 、每次请求消耗网络资源，并不是一个最优解

• 方案二：

起一个定时任务去定时的刷新这个 Token 问题：会引入新的框架，存在的风险未知，可用性不高！

需要在解决问题的情况下,尽量避免使用其他组件！（楼主用的是 Java 写的后端） 有无大佬能够给我一个不错的解决方案？

[SenLief]

不应该是现有 token 请求，如果失效了重新认证吗。

[kiracyan]

你这两个方案都不能保证 token 有效吧 正确的方式不是在请求第三方接口返回 token 错误的时候重新获取 token 吗

[ravelminerva]

失效时间未知吗?感觉对方的设计有问题.要不考虑使用 redis 缓存这个 token,如果失效了再重新获取 token

[itechnology]

token 失效时间未知？感觉只能每次都更新这个 token，除非这个第三方告诉你，他们的 token 一般多长时间失效。

[BBCCBB]

Oauth2 的 token 就是这样的,, 失效了就要用 refreshToken 去重新拿 token,

可以尝试失效报错的时候再更新 token, 然后重试?

[clf]

每次请求失败后都重新获得 token 再请求呗。然后设置一个重试次数，避免死循环。

[wolfie]

失效时间未知，是第三方 API 设计问题。

自定义维护一个 token 失效时间，比如 4 个小时。

单起线程 每分钟检查，有没有即将过期的，然后重新获取。

[dcalsky]

每次请求的大致步骤:
1. 从缓存中（ redis 、本地变量都行）获取 token 。为空 -> 步骤 2，不为空 -> 步骤 3
2. 向第三方 API 获取 token，并且保存到缓存中
3. 带着 token 去请求第三方接口，根据返回这判断 token 是否过期。过期 -> 步骤 2

[icelo]

@SenLief 不需要重新认证，重新请求下获取 token 的接口就行了

[icelo]

@ravelminerva 不考虑使用 redist

[ravelminerva]

@icelo 那就弄一个全局变量,失效了再去刷新,控制下并发就行了.

[kop1989]

1 、定时刷新为何会“会引入新的框架，存在的风险未知，可用性不高！”？？？
2 、可以每次请求接口的时候检查 token 的申请时间，然后判断是否需要刷新 token 。并不需要计时刷新。

btw：
在内存中保存一个 token，以及其有效期两个变量有这么难么？还需要“新框架”？？
至于说并发问题，给全局变量加锁即可。

[kop1989]

开源、组件化是趋势不假，但不要真的把自己弄成调参侠，引包侠。

[superrichman]

问是用 redis
起一个进程定时取 token 写 redis 刷新，业务只关心从 redis 里面取 token

[MonkeyJon]

1.请求其他系统 token 直接存 redis，过期 token 直接递归再次请求
2.使用 token 请求第三方 API 时，报错直接调用 token 刷新接口，然后调用 API

[hope4tomorrow]

public String getToken(){
if(isTokenExpire()){
this.apiToken = getNewToken()
}
return this.apiToken
}

[libook]

感觉 1 、2 楼是正解，Token 直接拿来用，返回说明失效再重新获取新 Token 。

[ch2]

常规做法是用中间件记下来 token 过期的时间，判断过期了再刷新

[skiy]

失效时间可以自己写程序尝试一下计算出来的吧？我不相信上游的 API 失效时间是随机的。

像楼上说的，用中间件保存，接口这边请求上游 API 发现 TOKEN 失效时，再刷新保存到中间件。这不是正常操作吗？

[lllllliu]

重新获取 token 呀，一般都有提供刷新接口吧，不需要重新获取 token，在 token 即将过期的时候去刷新他。
但是要再重新获取的时候锁住 token 或者拒绝其他请求～～要不然就会有并发问题。