Token取代Session的原因

一句话:
前后端交互过程中使用的token就是通过jwt生成的

一、JWT能做什么

  1. 授权
    这是jwt最常用的一个功能, 也就是用户登录成功以后给用户颁发一个token(令牌),使用这个token令牌可以访问后台的接口,【单点登录广泛使用了jwt】
  2. 加密
    通过jwt可以对参数进行签名, 后端可以通过设置拦截器验证参数的签名, 如果验证通过才真正进入后台进行处理

二、为什么选择jwt,session不香吗

  1. 会话追踪早期实现方式
    在早期系统中是通过session(服务端)保存用户登录信息,前端传递用户名和密码到服务端进行验证, 验证成功后将用户信息添加到session中
    1
    request.getSession().setAttribute("user",user);
    执行完这段代码,java会在服务器开辟一片内存用来保存用户信息, 也就是session,不同用户保存的session不互相影响

服务端session保存形式

然后响应一个set-cookie的响应头,浏览器根据这个请求头将JSESSIONID保存到cooke中
服务端set-session

然后之后的请求会自动将这个cookie携带到请求头中发送到后台,服务端通过这个JSESSIONID判断是哪一个session,也就能获取到当前登录的用户信息

发送请求携带Cookie

缺点:

  1. 用户信息直接保存在服务端内存中, 内存开销太大
  2. 必须是单机项目, 因为用户信息直接保存在服务器中, 如果有多个服务器(分布式),则无法正确拿到session信息
  3. 用户可以直接看到cookie信息, 不安全,容易受到CSRF攻击(跨站请求伪造攻击),比如可以直接通过cookie登录百度网盘,通过cookie+爬虫获取很多需要登录的网站的信息
  4. 包含的信息太单一, 只有JSESSIONID

    2. token验证方式

    认证流程:
    首先前端将用户名和密码发送到服务端, 登录成功服务端将用户的id和其他信息作为JWT的负载,将其与头部分别进行base64编码拼接后签名, 形成一个token,返回到前端
    前端保存token,并在每次发送请求时在Http请求头中加入Authorization请求头即可(axios可以统一配置)
    后端拦截请求, 并通过验证签名在判断token是否是服务端签发的,如果不是则不会处理, 否则进行正常的业务逻辑,正常返回数据
    优势:
  5. 可以通过参数或者请求头进行发送,数据量小,速度快
  6. token负载中包含了很多其他信息,避免查询数据库
  7. jwt跨语言,任何web形式都支持
  8. 不在服务端保存session信息, 对多服务支持友好