如何区分不同用户？Cookie/Session详解，基于Token的用户认证——JWT

Cookie和Session作用都是跟踪用户的整个会话。Cookie是存在于客户端的“客户通行证”，Session是存在于服务端的“客户档案表”。

Cookie：

为什么产生：一个用户的所有请求操作对应一个会话，另一个用户则对应另一个会话，但是由于HTTP协议的无状态特性，服务器无法单从连接上跟踪到会话。

来源：服务端response向客户端浏览器颁发Cookie，存储在客户端的浏览器中。

作用：当浏览器再次请求该网站时，浏览器把url+Cookie提交给服务器，在服务端进行验证。

操作：服务端操作Cookie类对象：

• 获取：request.getCookie()
• 添加：response.addCookie()
• 删除：没有提供删除Cookie的方法，设置maxAge(0)即为删除
• 修改：使用一个同名Cookie覆盖原始Cookie

性质：不可跨域 （域名不同的两站点，互不干涉彼此的Cookie）

编码方式：BASE64（保存二进制图片）；Unicode（保存中文UTF-8）

重要属性：

• name  Cookie名称
• value  Cookie值
• maxAge  Cookie失效时间（如果为0，即为删除cookie）
• secure  是否仅被使用安全协议传输，HTTPS、SSL
• path  Cookie的作用路径
• domain  可以访问该Cookie的域名

记住密码的实现思路：账号按一定规则加密后，连同账号一起保存到Cookie，下次访问时只需判断账号加密规则是否正确即可。

 

Session：

服务端使用的记录客户端状态的机制。Session相当于在服务器上建立的一份客户档案表。

生命周期：Session在用户第一次访问浏览器时自动创建，只要用户访问，服务器就会更新Session最后访问时间。

浏览器中新开的窗口会生成新的Session，但子窗口除外，子窗口共用父窗口的Session。

客户端如果不支持cookie怎么办？

URL地址重写：将用户的session id信息重写到URL地址中，服务器解析重写后的URL，获取Session id。

会话完整流程：

1. 用户输入登录信息。
2. 服务器验证信息，并创建Session，存储到数据库（Redis）。
3. 服务器为用户生成Session id，将带有Session id的Cookie放在用户浏览器。
4. 后续请求中，根据数据库验证Session id ，有效则接受。
5. 用户注销，会话在服务器和客户端都被销毁。

 

基于Token的鉴权机制——JWT

JWT：JSON Web Token。是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。是一段字符串，由三段信息构成，用“.”拼接。

• header  头部：存放签名、算法
• payload  载荷：存放不敏感信息
• signature  签证：存放密钥

注意：基于Token的鉴权机制类似于HTTP协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。由于每次请求时需要将Token传递给服务端，它应该保存在请求头header里。（服务端需要支持CORS策略，跨域设置CORS_ALLOWED_ORIGINS=["*"]）

优点：可扩展性好，在分布式部署中，Session需多机数据共享存到数据库，但是JWT不需要。

缺点：不能存敏感数据；JWT太长；一次性。

JWT适用场景：适用于有效期短，只希望被用一次的业务场景，比如：邮箱注册激活账户以及分布式站点的单点登录（SSO）场景。

存储方式：可以将JWT保存在cookie中，也可以保存在浏览器的本地存储。

浏览器本地存储：

• SessionStorage  临时存储（浏览器关闭数据失效）
• LocalStorage  永久存储（客户端不主动，数据一直存在）

操作SessionStorage 和 LocalStorage ：

• .变量名 = 变量值
• .setItem("变量名", "变量值")     // 保存
• .getItem("变量名")                    // 读取
• .removeItem("变量名")             // 删除