用户身份验证的令牌—Token教程

一、什么是Token？

1、Token的引入：Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。

2、Token的定义：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

3、使用Token的目的：Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

总结：

• 客户端使用用户名跟密码请求登录；
• 服务端收到请求，去验证用户名与密码；
• 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端；
• 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；
• 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；
• 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。

二、Token都可以解决哪些问题呢？

• Token具有随机性、不可预测性、时效性、无状态、跨域等特点。
• Token完全由应用管理，所以它可以避开同源策略
• Token可以避免CSRF攻击
• Token可以是无状态的，可以在多个服务间共享
• Token是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回Token给前端。前端可以在每次请求的时候带上Token证明自己的合法地位。如果这个Token在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。

当然说到这里大家可能会想到，用服务器的session_id存储到cookies中也能做到，为什么非要用Token呢？网上有许多对比Token和session的文章，在此就不再赘述。其实小编觉得，如果是开发web应用的话，用两者都可以，但如果是开发API接口，前后端分离，最好使用Token，因为session+cookies是基于web的，但针对API接口可能会考虑到移动端，app是没有cookies和session的。

三、Token的生命周期

1）用户未登录

用户执行注册/登录→

一旦基础数据校验成功，后端生成Token，并且Token包含此次注册/登录用户的用户名并通过JsonResponse返回给前端→

前端拿到返回的Token后，存入浏览器本地存储

2）用户每次访问博客页面

从本地存储中拿出Token→

JS将 Token 放入request的Authorization头，发送http请求向后端索要数据→

服务器接到前端请求（当前URL加了loging_check,并且请求方法在methods参数中）,进行校验→从requestAuthorization头拿出Token→校验→校验不通过，返回前端异常代码/校验通过，正常执行对应的视图函数→前端一旦接到关于Token的异常码，则删除本地存储中的Token,且将用户转至登录界面。

四、如何设置Token的有效期？

其实Token作为一个概念模型，开发者完全可以针对自己开发的应用自定义Token，只要能做到不让不法分子钻系统漏洞即可。

那么为Token设置有效期还有必要吗？

对于这个问题，大家不妨先看两个例子：

例1：登录密码

登录密码一般要求定期改变密码，以防止泄漏，所以密码是有有效期的。

例2：安全证书

SSL安全证书都有有效期，目的是为了解决吊销的问题。

所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token都需要设有效期。

那么，Token的有效期多长合适呢？

一般来说，基于系统安全的需要当然需要尽可能的短，但也不能短得离谱：如果在用户正常操作的过程中，Token过期失效要求重新登录，用户体验岂不是很糟糕？

为了解决在操作过程不让用户感到Token失效的问题，有一种方案是在服务器端保存Token状态，用户每次操作都会自动刷新（推迟）Token的过期时间。

如此操作会存在一个问题，即在前后端分离、单页App等情况下，每秒可能发起多次请求，如果每次都去刷新过期时间会产生非常大的代价，同样地，如果Token的过期时间被持久化到数据库或文件，代价就更大了。所以通常为了提升效率、减少消耗，会把Token的过期时保存在缓存或者内存中。

另一种方案是使用RefreshToken，它可以避免频繁的读写操作。这种方案中，服务端无需刷新Token的过期时间，一旦Token过期，就反馈给前端，前端使用RefreshToken申请一个全新Token继续使用。

这种方案中，服务端只需要在客户端请求更新Token的时候对RefreshToken的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然RefreshToken也是有有效期的，但是这个有效期就可以长一点了。

五、使用 Token 和 Refresh Token 的时序图

1）登录

 2）业务请求

3）Token 过期，刷新 Token

用户身份验证的令牌——Token - 知乎 (zhihu.com)

什么是token - 简书 (jianshu.com)

Token的详细说明，看这一篇就够了 - 简书 (jianshu.com)