JWT(Json Web Token)的原理、渗透与防御

（关于JWT kid安全部分后期整理完毕再进行更新~2023.05.16）

JWT的原理、渗透与防御

含义

JWT全称为Json web token，是为了在网络应用环境间传递声明而执行的一中基于JSON的开放标准。常用于分布式站点的单点登录。
JWT的声明一般被用在客户端与服务端之间传递身份认证信息，便于向服务端请求资源。

（我理解就是token验证的一种数据格式）

原理

1. 客户端提交用户名密码等信息到服务端请求登录，服务端在验证通过后前发一个具有时效性的token，将token返回给客户端

2. 客户端收到token后会将token存储在cookie或localStorage中

3. 随后客户端每次请求都会携带这个token，服务端收到请求后校验该token并在验证通过后返回对应资源

JWT的起源

有需求必然有其存在的道理，关于JWT的出现要先理解一下什么是传统session认证。
session认证
解决http协议本身并不能记录状态问题，session在每一次会话开始时产生，用于存放会话信息，每个session以键值对的方式生成（session_id=session），将session_id以cookie的形式（set-cookie）返回给客户端，客户端再次请求时携带session_id，服务端根据session_id使用对应的session作为认证信息为客户端响应对应服务。

听起来好像和JWT的原理差不多？不都是每一次会话的身份信息服务端发给客户端，存储在cookie当中，只是存储格式的差异么，一个是键值对，一个是json（严谨来说json也是键值对）。不急，继续往下读。

传统session认证问题

• 服务端开销问题：由于认证信息存储在服务端，当认证用户量增加时，服务端开销会明显增大。
• 扩展性不佳：由于存储在服务器端，意味着后续的请求也必须是在同一台服务器上才能响应对应资源，对于分布式应用，限制了负载均衡的能力以及应用扩展能力。
• CSRF攻击：由于存储在浏览器cookie中，CSRF攻击时，网站校验浏览器中cookie后会认为时用户本人操作。

token与session区别

由上面的原理来看其实两者是十分类似的，但实际上，session的认证信息是存储在服务端，客户端的session_id仅仅是session的标识符，而token本身就是携带认证信息的。而且由于token是可以通过一定的手段在请求时与cookie分离独立出一个首部字段，故token是可以防御csrf攻击的。其二token机制服务端是不存储相关认证信息的，只是对token做解密并根据解密信息查询用户信息，故对于服务端的开销更小，也更利于分布式服务器应用的扩展。

由此可以总结出来，JWT的优点，或者说相比session，token的优点主要有下面两点：

• 能存储更多认证信息，为服务器减轻负担。
• 可以与cookie分离出来࿰