初始JWT原理及实战
JWT简称JSON Web Token,也就是通过JSON形式作为Web应用中的令牌,用于在各方之间安全地将信息作为JSON对象传输,在数据传输过程中还可以完成数据加密、签名等相关处理
JWT能做什么
-
授权
这是JWT的最常见方案,一旦用户登录,每个后续请求将包括JWT,从而允许用户访问该令牌允许的路由,服务和资源,单点登录是当今广泛引用JWT的一项功能,因为它开销很小而且可以在跨域中使用
-
信息交换
JSON Web Token是在各方之间安全地传输信息的好办法。因为可以对JWT进行签名(例如,使用公钥/私钥对),所以您可以确保发件人是它们所说的人,此外,由于前面是使用标头和有效负载计算的,因此还可以验证内容是否遭到了纂改
为什么是JWT
基于传统的session认证
认证方式
我们知道,http协议本身是一种无状态的协议(连接请求和连接中断),而这就意味着如果用户像我们的应用提供了用户名和密码进行用户认证,那么下一次请求的时候用户还要再进行一次用户认证才行,因为根据http协议,我们并不直到是哪个用户发出的请求,所以为了让我们的应用能够识别是哪个用户发出的请求,我们只能在服务器存储一份用户登陆的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能够识别来自哪个用户了,这就是传统的基于session认证
认证流程
暴露问题
-
每个用户经过我们的应用认证以后,我们的应用都要在服务端做一次记录,以方便用户下次识别的鉴别,通常而言session都是保存在内存中,而随着认证用户的增大,服务端的开销会明显增大
-
用户认证以后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力,这也就意味着限制了应用的扩展能力
-
因为是基于cookie来进行用户识别的,cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击
-
在前后端分离系统中就更加痛苦了: 也就是说前后端分离在应用解耦后增加了部署的复杂性,通常用户一次请求就要转发多次,如果用session每次携带sessionid到服务器,服务器还要查询用户信息,同时如果用户很多,这些信息存储到服务器内存中,给服务器增加负担,还有就是CSRF(跨站伪造请求攻击)session是基于cookie进行用户识别的,cookie如果被截获,用户就很容易受到攻击,而且sessionid是一个特征值,表达的信息不够丰富,不容易扩展,而且如果你后端应用是多节点部署,那么就需要实现session共享不方便集群
基于JWT认证
认证流程
-
首先,前端通过web表单将自己的用户名和密码发送到后端的接口,这一过程一般是一个HTTP POST请求,建议的方式是通过SSL加密的传输(https协议),从而避免敏感信息被嗅探
-
后端核对用户名和密码成功后,将用户的id等其他信息作为JWT Payload(负载),将其与头部分别进行Base64编码拼接后签名,形成一个JWT(Token)。形成的JWT就是一个形同lll.zzz.xxxx的字符串
-
后端将JWT字符串作为登陆成功的返回结果返回给前端。前端可以将返回的结果保存在localStorage或sessionStorage上,退出登录时前端删除保存的JWT即可
-
前端在每次请求时将JWT方式HTTP Header中
-
后端检查是否存在,如存在检测JWT的有效性,例如,检查签名是否正确;检查Token是否过期;检查Token的接收方是否是自己
-
检验通过后后端使用JWT中包含的用户信息进行其他逻辑操作
JWT优势
-
简洁:可以通过URL,POST参数或者在HTTP header发送,因为数据量小,传输速度也很快
-
自包含,负载中包含了所有用户所需要的信息,避免了多次查询数据库
-
因为Token是以JSON加密的形式保存在客户端的,所以JWT是跨语言的
-
不需要在服务端保存会话信息,特别适用于分布式微服务
JWT结构
令牌组成
-
标头(Header)
-
有效载荷(Payload)
-
签名(Signature)
Header
Payload
令牌的第二部分是有效负载也就是自平衡,其中包含声明,声明是有关实体(通常是用户)和其他数据的声明
Signature
前面两部分都是使用Base64进行编码的,即前端可以解开知道里面的信息。Signature需要使用编码后的header和payload以及我们提供的一个密钥,然后使用header中指定的签名算法(HS256)进行签名,签名的作用是保证JWT没有被纂改过
HS256(Base64(header) + "." + Base64(payload),secret)
使用JWT
-
导入依赖
-
令牌的获取
-
令牌的验证
为了解耦我们需要工具类来帮助我们每次验证token
封装JWT工具类
Spring Boot整合JWT
导入依赖
配置文件信息
User类
Dao层
Service层
Mapper文件
用户登录成功后客户端将会保存一段token用户每次请求都需要带上这段token
拦截器
配置拦截器
项目目录
正常登录
错误登录
用户每次执行业务代码的时候都头部都需要带上token
Refresh Token
refresh token 是专用于刷新 access token 的 token。
Access Token 的有效期比较短,当 Acesss Token 由于过期而失效时,使用 Refresh Token 就可以获取到新的 Token,如果 Refresh Token 也失效了,用户就只能重新登录了。Refresh Token 及过期时间是存储在服务器的数据库中,只有在申请新的 Acesss Token 时才会验证,不会对业务接口响应时间造成影响,也不需要向 Session 一样一直保持在内存中以应对大量的请求。
__EOF__

本文链接:https://www.cnblogs.com/ccywmbc/p/16367031.html
关于博主:评论和私信会在第一时间回复。或者直接私信我。
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
声援博主:如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通