token的验证机制是怎样的？

Question

以下是我的理解，不知道是否正确：
1、登录成功后服务端会生成一个token作为唯一标示
2、token同时保存在后台数据库和客户端
3、客户端每次不用重新登录而是验证本地token和服务端token是否相等就可以
4、如果token过期就重新登录
还有一个问题，怎么实现token的时效性？如果token通过username、password生成，怎么才能使token在一段时间后过期？

Answer 1

不赞同3楼所说客户端不需要过期时间这个说法。

token应该是由服务端来最终决策，但前台也有必要了解过期时间，可以看一下我的token处理方式：

服务端: SQL/REDIS(减少数据库IO)  userid,token,expire,scope? 
// 后台expire最为简单 实时和当前时间戳进行比对 或者直接在数据库中 按照大于时间戳的筛选进行取出
手动设置过期 是在 取出后比较时间戳时需要做的, 可以直接将expire设置为0 或者删除行(不推荐) 可以写入服务器定期清理脚本中,使用Redis也是不错的选择

客户端: userid,token,expire |  tokens:{scope1:{token:'...',expire:150000000},scope2:{...}...}  
// 简单机制下 可以不需要scpoe(作用范围)

服务端不用说了,expire决定了token是否有效

而客户端最重要的是 有一个临期检查,最常用的场景就是 移动端的登录长期驻留,譬如说:
我们设定了30天的最长有效时间,同时我们的用户活跃频率在7天,
那么前台就可以去按周(灵活设置)的提前量去检查token ,如果用去 7/30的时间了,我们就在前台请求刷新token 这样就可以做到用户永久不登录的安全免登录. 当然 如果超过30天都没登录 这时候token过期 自然也就不能更新 需要手动登录了。

__ RE: 第三方token管理

关于第三方的token 其实要把自己的服务器当成是 客户端来理解就好了，逻辑是一致的,不过这里就一定存在scope了,以微信授权登录为例 我们拿到token的时候同时也会拿到 expires (有效时长) 那么我们要在自己的服务端存储成时间戳 time(true)+ expires*0.9 每次这样就可以 在token还未过期重新请求了。逻辑上和上面的客户端临检一致，实现上考虑到业务需求不同略有区别。

Answer 2

token中完全不必存储过期时间，什么时候过期由存储在服务端的token决定：服务端的token一般存储在类Redis的内存数据库中，时效由Redis控制。
当客户端发给服务token的时候，服务端会去redis检查是否有这个key（过期会被自动删除），从而实现了token的过期机制。顺便说一下，单点登录也可通过这个方式实现。

Answer 3

有相似的文章php JWT在web端的使用方法

Answer 4

token 可以加密为可解密方式
存储数据为：

[
    'user_id'     => 1,
    'create_time' => 152378273,
]
对数组进行加密返回给客户端，服务端接口收到 Token 解密就可以了

Answer 5

具体的案例：http://www.simengphp.com/inde...