通常 token 一般都是超时失效。如果想要 token 按使用次数失效（且后端不需要设计计数器），比如 token 用过一次就失效。
This topic created in 2499 days ago, the information mentioned may be changed or developed.
 |
1
HENQIGUAI Aug 29, 2019
redis incr
|
 |
2
inhzus Aug 29, 2019 via Android
超时失效的逻辑是，token 中有设置的超时时间的时间戳，在服务端和当前时间比较下就可以判断是否过期。
按次数失效的话，我直观上觉得仅凭 token 中的某个标志位是不可取的。看楼下大佬有没有好的想法，或者有其他不使用 token 达到次数失效的有意思的方法 |
 |
3
shalk Aug 29, 2019 via iPhone
比较时间戳和比较次数是一回事。你已经假定 token 不变，token 里只能带次数上限，后端肯定要知道已使用次数，要么放在外部，要么放在内部。
|
 |
4
momocraft Aug 29, 2019
想不出这样的 token 怎样抗重放攻击
|
 |
5
netnr Aug 29, 2019
这就是卡密需求，有时间、次数限制，比如说卡密有效期三个月，那么后台得记录三个月内的卡密兑换情况，超出月份的可以删除（前提是卡密是包含了年月信息）
楼下正解？ |
 |
6
zhujinliang Aug 29, 2019 via iPhone  2
除非服务器端有记录 token 使用次数，否则的话估计只能利用超自然现象了，比如：
token 中放一句诗或一张图片，会导致看到这个信息的人的时间减少一秒，服务器端可以通过比对正常时间流逝与请求方时间流逝的差别判断 token 被使用了多少次 |
 |
7
diegozhu Aug 29, 2019
1. 要么 token 里面加个 maxCount， 服务器端计数。
2. 要么 token 里面加个 visitCount，每次都 refresh token，当 visitCount >= server 端配置的 maxCount，就不允许 refresh token. token 是不变的，类似 readonly。只有 token 过期重新获取才会改变。大部分这种计数的需求都是放在 server 端做。 server 端不计数可以通过第二种方式，但是第二种方式，就违背了 token 作为令牌的设计理念了。本来只要持有令牌，则可在一定时间内访问，变成每次都要 refresh 了。 所有请求都要 refresh，会对系统压力好大。本来只需要验证下 token 是否有效，现在每个请求都要重新生成一个 token....很容易成为瓶颈。 |
 |
8
chinvo Aug 29, 2019 via iPhone
@diegozhu #7 第二个方案有个疑点，如果客户端不请求刷新 token，那么 visit count 不会变化，并且此 token 仍然有效
|
 |
9
skiy Aug 29, 2019
用 redis，反正 token 我都是用 redis 来存的。
|
 |
10
ipwx Aug 29, 2019 via Android
不论是计数还是计时，服务器不存是不可能的
|
 |
12
a719114136 Aug 29, 2019 via Android
你后端不想存，只能把数据加密发给前端，前端再返回给你。
当然这样是放弃了安全 |
 |
13
orcusfox Aug 29, 2019
TOTP 和 HOTP ？不过有一定限制
|
 |
14
wysnylc Aug 29, 2019
访问一次 redis+1,达到限定次数后返回限制异常信息
解析问题,别把简单问题复杂化 |
 |
15
nmdx Aug 29, 2019 via Android
虽然我是一个外行，但你这说的不就是卡密嘛。。。
|
 |
16
zhang77555 Aug 29, 2019
后端判断这个 token 是否有效和还能用几次 基本没啥差别
|
 |
17
whp1473 Aug 29, 2019
服务端不存就是 jwt 那种，每次生成一个新的 token，但是重放攻击你怎么防止，被使用过的仍然符合你的验证规则。所以按次这种，服务端必然要存。
|
 |
18
Yanni0507 Aug 29, 2019
@zhujinliang 过于暴力，加急处理吧
|
 |
19
robinlovemaggie Aug 30, 2019
你这明显是想将 session 的事情交给 token 做，有点强人所难。
|
Select Language