[JAVA EE]session 和 token 机制

HTTP 协议是无状态的。

• 即服务器对于客户端每次发送的请求都认为它是一个新的请求。
• 本次请求和上次请求无法判断是不是同一个客户端操作的。

随着 Web 应用的发展，如在线购物网站，需要登录的网站等，马上就面临一个问题，那就是要管理会话，必须记住哪些用户登录了系统，哪些用户往自己的购物车中放了商品， 也就是说必须把每个用户区分开。

---

session 机制

• session 是一种记录服务器和客户端会话状态的机制。
• session 主要用来存储所有访问过该服务端的客户端的用户信息（也可以存储其他信息），从而实现保持用户会话状态。
• session 是基于 cookie 实现的，session 存储在服务器端，sessionid 会被存储到客户端的 cookie 中。

注：cookie 是浏览器访问服务器后，服务器传给浏览器的一段数据(key-value)

cookie 特点：

• cookie 存放在客户端
• cookie 有个数限制(不同浏览器的cookie个数不等) ，
• cookie 大小一般是4K，
• cookie 可设置失效时间(如果没设置，默认是关闭浏览器时失效)，
• cookie 是不可跨域的(当前域名下有效)。

session 工作流程

• 浏览器在第一次访问服务器时，服务器会创建一个 session，代表用户的一次会话过程，服务器会为每一个 session 都分配一个唯一的 sessionid，以保证每个用户都有一个不同的session 对象。
• 服务器在创建完 session 后，同时会创建一个特殊的 cookie（name为JSESSIONID，value为sessionid），并将该 cookie 发送至浏览器端。
• 当用户向服务器发送新的请求时，浏览器会携带这个 cookie 对象，把 sessionid 传回给服务器，服务器根据 sessionid 找到与该用户对应的 session 对象，从而区分不同用户。

session 登录验证机制

用户在登录认证成功之后，并且往 session 对象里面放入了用户登录成功的凭证，才能用来进行真正意义上的管理会话。

session 机制存在的不足

• 开销问题：服务端需要保存每个用户的 session 信息，当用户越来越多时，内存的开销也会不断增加；
• 持久化问题：解决重启服务器后session就消失的问题。在数据库中存储 session，而不是存储在内存中；
• CORS问题（跨域共享）：在服务器A上登录， sessionid 保存在A上，假设下一次请求被转发到服务器B怎么办？会限制了服务器扩展能力；
• CSRF问题（跨站请求伪造）：session 伪造/劫持等安全性问题。

---

token 验证机制

token 是服务端生成的一串字符串，作为客户端进行请求的一个令牌。

• token 认证流程：
• 客户端使用用户名跟密码请求登录
• 服务端收到请求，去验证用户名与密码
• 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
• 客户端收到 token ，会把它存储起来，如存放在 cookie 或 localStorage 中
• 客户端每次向服务端请求资源的时候需要带着服务端签发的 token(注：token 放到 HTTP 请求的 Header 里)
• 服务端收到请求，然后去验证客户端请求中的 token ，如果验证成功，就向客户端返回请求的数据。

token 验证流程图示

token 验证流程

token 数字签名

token 机制优点

• 服务端无状态：服务端不存储 token 信息， token 存在客户端中。
• 可扩展性好：不存储 session 信息，负载均衡器能够将用户信息从一个服务传到其他服务器上。
• 支持跨域访问：CORS(跨域资源共享)
• 安全性：token 通过HTTP header传送，防止CSRF(跨站请求伪造)
• 基于标准：如JWT标准。JSON Web Token，最流行的跨域认证解决方案