站群cms系统,公司企业网站有哪些,备案 网站起名,外贸通道支持asp的网站吗一、JWT#xff08;Json Web Token#xff09;能干什么
1、安全认证#xff08;权限认证#xff09;
比如登录系统的时候#xff0c;服务器会检查前端请求数据中携带的token信息#xff0c;符合标准则允许访问#xff0c;不符合则拒绝你的访问请求。
2、信息传递
比…一、JWTJson Web Token能干什么
1、安全认证权限认证
比如登录系统的时候服务器会检查前端请求数据中携带的token信息符合标准则允许访问不符合则拒绝你的访问请求。
2、信息传递
比如两个系统之间传递信息a服务器向B服务器发送token信息b服务器对token进行解签名发现签名对的上就接收数据对不上就拒绝a服务器发来的数据访问。
二、JWT组成 头header.负载payload.签名signature 头、负载、签名三个部分组成并用点符号衔接。
头放签名用的加密算法
负载一些不敏感的用户信息通过base64编码放在负载中
签名头负载加密后的签名也称密钥
三、为什么要用Session或JWT认证机制
因为HTTP是无状态的网络协议比如一套系统势必会存在很多次请求而你的每一次请求服务器都不知道一个个请求是你发送的还是别人发送的就会造成你已经登录成功进入页面搜索某个东西点击确认发送了一个搜索数据的请求然而服务器已经不记得你是谁、是否登录成功然后听都不听你的请求就被服务器关在门外了因此你的每一次亲求都要进行一次身份验证但总不能每发送一次请求都要输入一遍账户密码来验证你是具备请求权限的吧所以你再一次登录请求成功的时候就给你发一张“通行证”后面同一个系统内部的请求都带上这张“通行证”表示你在这个系统中有相应的权限人后尽管说出你的请求服务器看到你的“通行证”“心领神会”“理所当然”接受你的请求然后根据你的请求在“能力范围内”响应你的请求。
三、Session和JWT认证机制的区别、优缺点
1、Session流程
客户端第一次向服务器发送请求验证身份身份验证通过服务器生成JSESSIONID放在cookie身上响应给客户端浏览器浏览器吧cookie保存在浏览器中下次请求时找到对应的cookie放在请求头一并发送到服务器服务器根据cookie信息验证身份验证成功查看你的请求作出响应。
2、Session缺点
[1]每当一个用户第一次发送请求生成sessionidsessionid就会被存储在服务器内存中当请求用户增多服务器开销随之变大
[2]某一用户第一次发送请求生成的sessionid存储后该用户以后发送的每一次请求都只能到特定服务器中申请访问资源不利于分布式负载均衡
[3]sessionid是通过cookie传送哎浏览器和服务器之间来回传送的容易被跨站请求伪造攻击
[4]前后端分离项目不易部署同一个系统需要发送很多个请求而session、cookie认证技术并没有减少每次都要进行搜索用户信息进行身份认证的动作
3、JWT认证流程
浏览器第一次向服务器发送请求的时候服务器生成一个令牌之后这个令牌不再保存在服务器中而是在保存在客户的浏览器中释放服务器的内存。往后客户只需要携带令牌请求数据就可以了而且服务器只用判断令牌是否有效就行了。也就是说JWT中有客户信息解码后获取用户信息直接验证权限不用额外再去数据库查用户信息、比对来验证用户权限。另外token会被存在浏览器的sessionStorage或者local Storage中当系统退出登录的时候token就会被删除释放浏览器内存。
另一番理解header
cookie将用户信息如账号、角色信息不包括密码等敏感信息以明文 方式存储在浏览器中服务器直接根据header携带的信息验证用户身份。相对于session缺乏安全性。
session给一个id给cookie服务器根据这个id查询数据库验证用户身份。相对安全。
JWT将用户信息以base64编码字符串给cookie存储在用户浏览器服务器获取header中的Authorization或URL或cookie中携带的token中的解码解签名之后的用户信息进行用户验证。相对于session缺乏安全性。
4、JWT优势
[1]token本身就有用户信息。只需要解密就可以直接获得用户信息数据而不用再取数据库查询数据了简单的查询还好就怕复杂数据地查询。
[2]保存在用户浏览器中释放服务器的部分内存压力
5、JWT缺点
[1]token在传输的过程中有被截获被人拿去冒充用户请求内部数据的风险 1、不安全的存储方式一些开发人员可能会把token存储在local storage、cookie、URL参数等不安全的位置容易被攻击者获取到。 2、使用http协议传输tokenhttp协议是明文传输攻击者可以通过中间人攻击截获token。 3、token窃取过程中的漏洞部分应用程序没有对用户输入做充足的过滤和检查攻击者可以通过在输入框中注入特定代码来盗取token [2]一旦签发一个jwt在到期之前就会始终有效无法中途废弃。例如你在payload中存储了一些信息当信息需要更新时则重新签发一个jwt但是由于旧的jwt还没过期拿着这个旧的jwt依旧可以登录那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题我们就需要在服务端部署额外的逻辑例如设置一个黑名单一旦签发了新的jwt那么旧的就加入黑名单比如存到redis里面避免被再次使用。
