大概因为知识浅薄，所以当想要描述什么事情的时候总会感觉自己无从说起，但是闭门造车也只能导致知识越发浅薄，只能简单说说自己关于token的思考，如有错误，希望指正。
1、有关token
token是经过了登录验证之后，由服务器端生成的一串包含了用户信息的加密串，作为用户接下来访问相关内容的通行证。相比于直接保存用户账号密码，每次需要访问相关内容的时候都要进行一次登录验证，token形式更加安全。一般来说基于token的身份验证有以下过程。
a) 客户端传递账号密码，服务器端进行身份验证并生成token传递给客户端
b) 客户端将token存储，保存在 Cookie 里或者 Local Storage 里
c) 客户端带上token向服务器请求数据，服务器对token进行验证后决定是否可以向客户端传递相关内容
2、token的生成与验证
我曾一度犹豫token是否有什么公用的生成规则，后面想想大体应该差不离，但是具体的应该各有不同。
token一般需要包含两种信息：一是用于用户身份验证的签名信息，二是关于token是否过期的时间戳信息。我对token的生成以及验证有过几种想法，有一个是服务器端随机生成token，然后将用户+token+生成时间（过期时间）存在数据库中，下次用户访问时就去看数据库里边的数据对不对的上，这个想法没有实现过，但是后面想想有点奇怪，不是很清楚这个是否能作为一个做法，还是说这个做法增加数据库开销或者其他原因并不推荐。
后面我选择了用户签名信息+时间戳信息加密生成token，而每次验证的时候需要将token重新解密，分成签名与时间戳分别验证。签名验证则需要将相关信息（用户独特的信息）以同样的方法加一次密后进行比对。时间戳则比对是否过期，如果过期则不通过验证，如果没有过期但是快过期了可以生成一个新的时间戳的token，发还给客户端。
3、token具体的生成规则
这部分大概是从我能看到的一些有关token生成规则的疑惑，不同网站token的生成应该具有独创性，不然被别人掌握了似乎便不太安全了，所以只是一些思考。
我看到一篇文章说：用户信息签名+时间戳信息进行base64编码后作为token，base64并不能算作加密算法，而token并不难取到，很容易就能取到 用户信息签名和时间戳信息，最简单的更改一下时间戳再进行base64编码就可以绕过登录验证访问信息了。所以用户信息签名这部分应该是会有更加复杂的变化的信息。譬如说，包含客户端的一些信息，就能保证用户更换电脑、更换网络、更换浏览器等等操作都需要重新进行登录生成新的token才可以进行访问。然而，同一个电脑、同一个网络环境、同一个浏览器，是否就该容忍用户拿着这个用户信息签名，改一改时间就可以无限次访问无需多次登录？或许可以在用户信息签名中也加入一些日期相关的信息，譬如服务器端统一的一段时间就更新的口令作为加密密钥或者作为掺入加密前明文的信息？或者就不该将base64作为最后唯一的加密手段。
我曾在一个小网站，用同一个token换不同浏览器访问都可以，不过倒是包含了过期的验证，也不是base64编码。所以token的安全性考虑应该看具体需求吧。
参考：