Cookie Session Token JWT

HTTP是无状态的协议（每次客户端和服务端会话完成后，服务端不会保存任何会话信息）。

问题：

每个请求都是完全独立的，服务端无法确认当前访问者的身份信息。

11.1 Cookie

cookie是服务端发送到用户浏览器，保存在本地的一小块数据，它会在浏览器下次向同一个服务器发起请求时被携带并发送到服务器上。

11.2 Session

session是 一种记录服务端和客户端会话状态的机制，使服务器有状态化，可以记录会话信息。
session是基于cookie实现的，session存储在服务端，sessionId存储在客户端的cookie中

11.2 Cookie-Session 认证模式

1.用户第一次请求服务器时，服务器根据用户提交的相关信息，创建对应的session
2.请求返回时，将session的唯一标识信息sessionId 返回给浏览器
3.浏览器接收到服务器返回的sessionId后，将其存入到cookie中，同时在cookie中记录，该sessionId属于哪个域名
4.当用户第二次访问服务器时，请求会自动判断该域名下是否有cookie信息，如果有会在发送时携带cookie，服务端从cookie中获取sessionId，根据sessionId在内存中查找对应的session信息，如果没找到 说明用户没有登录或登录信息过期，如果找到证明用户已经登录，可以执行后续操作。

该方式存在的问题

1.服务端需要存储session，且由于session需要经常的快速查找，通常存放在内存或内存数据库中，当同时在线用户数较多时，需要占用服务器大量的资源。
2.扩展性不好，在服务器集群的情况下，要求session数据共享，每台服务器都能够读取session。

11.4 Token

• Access Token

访问资源接口（API）时所需要的资源凭证

token的身份认证流程如11.5

• Refresh Token

用来刷新access token的token。

当access token过期时，如果不使用refresh token，则用户需要再次输入用户名和密码。有了refresh token，客户端直接用refresh token去更新access token，无需用户进行额外操作。

1.access token的有效期较短，当access token过期失效后，使用refresh token可以获取新的access token，如果refresh token也过期，用户需要重新登录
2.refresh token 及其过期时间 存储在服务器的数据库中，只有在申请新的access token时才会验证。

11.5 基于Token的认证模式

1.客户端发送登录请求，携带用户名，密码。
2.服务端收到请求，查询数据库验证用户名密码
3.验证成功后，服务端生成一个token，并把这个token发送给客户端
4.客户端收到token后，将其存储起来
5.客户端访问需要认证的接口时，在URL参数或HTTP Header中 加入Token
6.服务端收到请求，解析token，去数据库查询token中的信息，如果验证成功，就向客户端返回请求的数据

该模式对比 cookie-session模式 解决的问题

1.服务端不需要存储session，用解析token查询数据库花费的时间 来换取session的存储空间，减轻服务器的压力。

11.6 JSON Web Token (JWT)

其定义了一种基于Token的会话管理规则，涵盖Token需要包含的标准内容和Token的生成过程。

原理：

服务器认证之后，生成一个JSON对象，发回给用户。以后，用户与服务器通信时，都要发送这个JSON对象，服务器完全只靠这个对象认证用户身份。为了防止用户篡改数据，服务器在生成这个对象时，会加上签名。

11.6.1 JWT的数据结构

它是一个很长的字符串，中间用点（.）分割成三部分。

Header（头部）
Payload（负载）
Signature（签名）

Header

JSON对象，保存JWT的元数据，指定签名所用的算法，令牌的类型。
之后将JSON对象使用算法转成字符串

Payload

JSON对象，用来存放实际需要传递的数据，除了官方规定的字段还可以定义私有字段
由于JWT默认不加密，不能把秘密信息放在这个部分
之后将JSON对象使用算法转成字符串

Signature

对Header和Payload的签名，以防止数据篡改
根据Header中指定的签名算法，配置文件中指定的密钥，将前两部分的内容生成一个签名。

生成签名后，将三部分拼成一个字符串，每部分用点(.)分隔。

11.6.2 JWT的使用方式

客户端收到服务端返回的JWT，可以存储在Cookie或localstorage中。
此后，客户端每次与服务器通信，都要带上这个JWT,将其放在HTTP请求的头信息Authorization字段里面

11.6.3 JWT的特点

1.JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。

2.JWT 不加密的情况下，不能将秘密数据写入 JWT。

3.JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。

4.JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

5.JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

6.为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

12. 限制同一账号同一时间只能登录一个设备

不同设备登录同一账号时，登录时间肯定存在差别，由于登录时间的不同，所生成的token也会不同。

服务端生成token后，在redis中存入key = userId,val = token的对应关系。

当服务端接受到token后

1.解析token查看是否有效
2.解析token得到的user_id 用user_id查询redis中是否有对应的token
	如果有，将查询得到的token 与 客户端传过来的token 进行比较
		如果不同，说明是该账号再次进行登录操作，则将user_id对应的token 替换为 新的token
		如果相同，说明 用户使用之前登录生成的token 进行操作
	如果没有，则说明token错误或token过期