需求是要求前端研究一下如何给登录认证自动续期

这个是前后端都得做的事啊，双 token 机制，建议了解一下

accessToken refreshToken?

续期这事儿就该前端干，谁来我都这套说法。

技术方案上，token 应该有两个有效期 expire_at 和 refresh_expire_at, 后端应该提供一个 refresh 接口，当 token 过了 expire_at 有效期但是尚未到达 refresh_expire_at 有效期时，token 的鉴权能力失效，但是仍然可以访问 refresh 接口换取新的 token 。

要我说以前 Cookie: Set-Cookie: 明明玩得好好的，非得自己手搓 Authentication: 不嫌麻烦。。。。

双 token 这个确实没问题 如果真是这样子的话我就没有问题了 。。问题是。 服务端提供的整套登录接口以及用户认证逻辑全都是单一的一个 token 认证结构。 没有双 token 。也就是说。前端这边有一个登录接口 拿到的是返回的单次登录认证的一个 token 。 过期了。现在怎么办。。。

去看看 OAuth 协议

@javalaw2010 额，你把后端要干的事情都干完了，剩下可不就是前端干。OP 的说法看起来就是只有一个 token, 前端来干可不就只能保存用户密码，然后在过期的时候调用登录接口，这样做还要求登录接口不能有图形验证码这种东西。

@javalaw2010 你都没搞懂双 token 的精髓在哪，分成两个 token 就是为了隔离，refresh token 只在续期时用，被截获的概率大大降低。用同一个 token 去续期，每个请求都能截获一个能续期的 token ，风险大增。

如果有 token 续签的机制，前端定期请求一个查询接口保持一下就好了。
纯前端去做太蠢了……

也不知道你的插件是什么插件，如果是内部使用的插件，后端搭配一起改造一下 refreshToken 不就好了嘛。

@javalaw2010 好办法。 前提是后端给我提供一个换 token 的接口。我这就去找后端打架

让后端发个续期信息给你, 通过信息置换出新 token 或者直接拿到 token, 啥都不改就要续期, 要不然就扔掉安全性吧

总需要后端配合一下才能做吧。

最新消息， 打赢了！ 领导一刀切，什么 token 续期 先滚蛋。token 过期了滚回去重新登录

双 token 最佳，实在没法子只能定时器，但太脏了。

抛开单 token 的不安全性不谈的话.

你不用等过期,定时主动帮用户刷一下 token 不就完事了...

假设单 token 的有效期是 1 天,你就每天刷.
如果是 1 个月,你就每个月刷一次.

双 token ，前端要做完善还挺多事情的，要考虑并发请求和刷新之后重新请求的处理。不过这些现在方案都挺成熟了，可以去了解一下

op 问题双 token 就能实现吧，但我想问下怎么让 accessToken 和 refreshToken 长期有效？好像 b 站和油管没触发风控完全不会重新登录，是每次进入的时候都刷新两个 token 时效吗？如果是应该在什么时候触发刷新？

@bagel 双 token 对 OP 的业务来说，前后端的改造都太大了。我认为安全是相对的，并不是所有业务都需要双 token 机制，只要保证信道是 https 的，对绝大部分业务来说，单 token 机制已经足够，上古时代大家都用 Cookie/Session 鉴权也都过来了。而且 OP 公司一直以来都用的单 token ，这要是改双 token ，不知道多少开发要骂娘。

后端做，单 token ，认证拦截器里自动续期

先问问阿里云和腾讯云再说…这俩货，直接就是，要求重新登录…

恰好最近找了下双 token 的资料，但感觉和这个楼里面说的不太一样……refreshtoken 是给终端用的吗？

@lambdaq chrome 对跨域 cookie 的限制已经越来越多了，除非不提供对外服务，不然使用 token 是必然的。

@javalaw2010 #3 word 哥，没有什么是绝对的。refresh_token 能不能放在 cookie 里且 HttpOny ？如果可以是不是更科学是不是需要后端处理？

@yeqizhang #21 理论上 ttl 长的的 refresh _token 应该被放在 httpOnly 的 cookie 里，access_token 放在 localstorage 里面，但是实践中很多时候 access_token 和 refresh_token 都放在了 localstorage 里了。这两种实现方式都是双 token ，后者前后端分离更友好点。

@javalaw2010 Refresh 接口不就是后端写的 怎么就纯前端了

@accelerator1 限制是多，难不成比 Authentication 头还多？

纯前端方法每晚偷偷调用登录接口更新 token 参考某公司车机清积碳功能

@yeqizhang 和终端没关系, 任意客户端(app, 浏览器, 甚至服务端也是客户端(相对于别人的服务))



// 上个伪代码
var tokenCache, refreshCache


beforeMiddleware = func(req) {
----req.headers.set('token', tokenCache.get())
}
afterMiddleware = func (req, resp) {
----// 内部统一或者三方服务的公共状态码
---- if resp.statusCode == 401 {
--------// 上锁, 防止其他请求用到过期的 token, 也可以不锁, 看需求
--------tokenCache.lock()
--------resp = http.withOutMiddleware().post(refreshTokenUrl, {"token": refreshCache.get()})
--------refreshCache.set(resp.getRefreshToken())
--------tokenCache.unlock()
----}
}

http.addMiddleware(beforeMiddleware , afterMiddleware)
http.get(api)

那就双话事人咯

token 时间给长点，比什么都好使。

@skiy 国内大部分厂商都是验证 active-timeout 的，超过这个时间不活跃或者 token 过期就要求重新登录。

accessToken refreshToken

今年新目有完成功能 全公司也人理解我在什 真搞笑

我司用的是 accessToken refreshToken