个人简介:一个不甘平庸的平凡人
️ 本系列专栏:Node.js从入门到精通
️ TS知识总结:十万字超详细TS知识点总结
你的一键三连是我更新的最大动力❤️!
欢迎私信博主加入前端交流群
之前我们对 Cookie&Session的工作原理 做了详细的介绍,并提出了它存在的两个问题:存储问题和CSRF问题。为了解决/避免这些问题,开发者们开始使用更加成熟的JWT
来代替Cookie&Session
作为登录验证的首选技术方案,这一节我们就将详细讲解JWT
登录验证的工作原理。
在说JWT
之前,我们需要先了解一下传统使用Token
的方式。
Token
的意思就是“令牌”,是服务端生成的一段加密字符串(要保证唯一性),传统使用Token
做登录验证的流程:
客户端登录成功后,由服务端计算生成Token
并进行保存(一般是保存到数据库中)。
服务端将生成的Token
返回给前端(一般是将Token
添加到请求的响应头response.header
上)。
客户端拿到Token
后将其存储到本地,一般是存放到LocalStorage
中
客户端每次向服务端发送请求时都要带上它存储的这个Token
(一般是将Token
添加到请求的请求头request.header
上,这大多都是通过axios
的请求拦截进行实现)。
服务端收到请求后,验证客户端请求里携带的Token
是否与数据库中保存的Token
一致,若验证成功就正常响应请求。
如果希望Token
验证成功后服务端能获取或返回该Token
对应的用户信息,那么服务端在第一次存储Token
时就可以选择将Token
与用户信息进行关联存储,比如将Token
作为key
、用户ID(userId
)作为值:
{
Token:userID
}
这个流程与Cookie&Session
很是相识,不同的是,它没有引入SessionId
的概念,也没有使用cookie
,所以相比Cookie&Session
而言,传统使用Token
验证的方式避免了CSRF攻击问题,但并没有避免存储问题。
JWT的全称为Json Web Token,它和传统使用Token
的区别主要体现在服务端是否保存Token
。
通过JWT计算生成的Token
字符串(我们称其为JWT Token
)包含三个部分:
图片是经过翻译的,部分中文显示不准。
关于JWT Token字符串的更多细节可查阅这篇文章。
通过JWT Token
三段式的结构我们可以知道:
JWT可以将用户信息通过服务端的密钥加密到JWT Token
字符串中(Payload
部分),那么服务端同样也能从JWT Token
中解密出用户信息。
后续服务端只需将JWT Token
的前两部分(Header
与Payload
)与服务端保存的密钥进行计算,若计算结果与JWT Token
的第三部分(Signature
)相同即可验证该JWT Token
有效。
通过JWT Token
本身就可以进行验证和读取信息的操作,所以服务端就不需要存储Token
了,这就解决了传统使用Token
验证中的存储问题。
客户端登录成功后,由服务端根据自己的密钥和用户信息计算生成Token
。
服务端将生成的Token
直接返回给前端(一般是将Token
添加到请求的响应头response.header
上)。
客户端拿到Token
后将其存储到本地,一般是存放到LocalStorage
中
客户端每次向服务端发送请求时都要带上它存储的这个Token
(一般是将Token
添加到请求的请求头request.header
上,这大多都是通过axios
的请求拦截进行实现)。
服务端收到请求后,通过自己的密钥验证客户端请求里携带的Token
是否有效,若有效就正常响应请求。
整个流程中服务端只需要保存一个固定的密钥即可,其它信息全部由客户端进行存储,服务端做的工作只有生成token , 然后验证token。
优点:
缺点:
session_id
更大,需要消耗更多流量,挤占更多带宽,JWT中存储的数据越多,消耗的流量也就越多。token
被其他人利用,无法对其进行拦截(这其实和session id
被其他人利用是一样)。Payload
是使用base64
编码的,并没有加密,因此JWT
中不能存储敏感数据。博主的Node.js从入门到精通专栏正在持续更新中,关注博主订阅专栏学习Node不迷路!
如果本篇文章对你有所帮助,还请客官一件四连!❤️