基于 Token 的用户认证

用户认证

用户认证是互联网服务中重要流程，决定了服务的安全性。生活中靠身份证，网络上就要靠帐号和密码。HTTP做为一种无状态协议，没办法记住用户的登陆状态。所以咱们须要借助一些手段，来判断用户的登陆状态，从而决定用户是否具备操做权限。

用户认证：

1. 传统Session用户认证
2. 基于Token的用户认证

基于Session的用户认证

早期互联网使用Cookie(客户端)和Session(服务端)来记录和认证用户信息。Session与Cookie均是用来记录一系列状态，的区别在于Session是记录在服务端的，而Cookie是记录在客户端的。

认证流程：

1. 用户向服务器发送用户名和密码。
2. 服务器验证经过后，在当前对话（session）里面保存相关数据，好比用户角色、登陆时间等等。
3. 服务器向用户返回一个 session_id，写入用户的 Cookie。
4. 用户随后的每一次请求，都会经过 Cookie，将 session_id 传回服务器。
5. 服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

缺点

1. Session 须要存在服务器内存中，这样就不能跨实例共享。当下一次请求被分发到另外一个实例的时候，须要从新登陆。
2. 在高并发状况下，Session 须要放在内存中，受限于服务器内存的大小。Token只须要在服务器进行解析验证。
3. Session 依赖于浏览器的 Cookie 机制，对于部分软件和移动客户端很难支持。而Token不只在Web仍是移动端都有很好的支持。

由于种种限制，如今普遍使用的是基于Token的用户认证。

基于Token的用户认证

token 是登陆以后服务器返回的一段加密字符串（加密算法有多种），存储到本地。在客户端请求服务端数据的时候能够带上（放在请求头headers，参数都行），如下只是思路。

认证流程

1. 当用户登陆成功后，服务器端就会经过指定算法生成一个 token，将token 存放在 redis，再将这个 token 值返回给客户端。
2. 客户端将 token 存储在 localstorage 或 sessionstorage中 (小程序能够存放在 app.global )。
3. 当客户端调用接口请求数据时，携带 token 值发送给服务器。
4. 服务器接收到客户端的请求以后，会先解析返回的 token 获得用户信息验证，并取出 token 值与保存在 redis 的token值作对比。
5. 若是token对比成功，说明用户处于登陆状态，不然表示登陆状态失效，须要用户从新登录。用户每次从新登录会刷新token的过时时间。