如何实现用户登录后生成token,以及验证token并提取用户信息
问题原因分析:在传统的项目中我们利用,session+cookie来保持用户的登录状态,但这在前后端分离项⽬中出现了问题;sessionid是使用cookie存储在客户端的,而cookie遵守同源策略,只在同源的请求中有效,这就导致了问题出现:前后端分离后静态资源完全可能(而且经常…)部署到另一个域下,导致cookie失效。
虽然我们可以在cookie中指定domain来解决,但是cookie必须针对性的设置作用域,这对于有多个不同域要共享cookie时,可操作性差,难以维护。正因为有这些问题,导致session+cookie的方式在某些项目中使用起来变得很麻烦,这时候就需要⼀一种新的状态维持的方式-JWT工具类。
JWT工具类
一、概述
JSON Web Token(JWT)是一个轻量级的认证规范,这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。其本质是一个token,是一种紧凑的URL安全方法,用于在网络通信的双方之间传递。它的亮点是安全、稳定、易用、支持JSON。原理是JWT可以对用户信息进行加密生成一个字符串,下发到客户端,客户端在后续请求中携带该字符串,服务器解析后取出用户信息,从而完成用户身份的识别。
二、JWT组成
一个JWT实际上就是一个字符串,它由三部分组成,头部、载荷与签证
头部用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。
载荷就是存放有效信息的地方
- 标准中注册的声明(建议但不强制使用)
- 公共的声明
公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.
(3)私有的声明
私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息。这个指的就是自定义的claim。这些claim跟JWT标准规定的claim区别在于:JWT规定的claim,JWT的接收方在拿到JWT之后,都知道怎么对这些标准的claim进行验证(还不知道是否能够验证);而private claims不会验证,除非明确告诉接收方要对这些claim进行验证以及规则才行。
三、JWT的使用
1.在pom.xml里加入以下依赖
2.用户类
3.生成JWT:
4.验证JWT及提取数据:
四、JWT工具类的优缺点
JWT工具类的优点主要包括以下几个方面:
1. 简化处理
JWT工具类封装了JWT的生成和解析过程,使得使用者可以不必了解JWT的细节就可以轻松实现JWT功能。
2. 安全性高
JWT工具类实现了签名的生成和验证过程,通过指定签名算法和密钥可以有效地避免信息在传输过程中被篡改的风险,保证了信息传输的安全性。
JWT工具类的缺点主要体现在以下几个方面:
1. 客户端存储问题
由于JWT是无状态的,因此在认证过程中需要将所有的信息都包含在JWT中,这就使得JWT变得较为臃肿。同时,JWT也需要被存储于客户端,如果存储在cookie中,就容易受到 CSRF(跨站请求伪造)的攻击;而如果存储在localStorage中,则容易受到 XSS(跨站脚本攻击)的攻击。
2. 无效验证问题
由于JWT是无状态的,一旦签发后,就无法使其失效。即使将JWT存储在数据库或者Redis中,也只能通过删除来使其失效,而这样往往需要对数据库或者Redis进行频繁的访问和更新,影响系统的效率。
五、总结
JWT工具类是实现JWT功能的重要工具。通过对JWT工具类的详细阐述,我们可以了解到JWT的实现原理和如何应用于具体场景。同时,我们也需要注意到JWT工具类的优缺点,避免在使用JWT工具类时出现问题。