【JWT】

最新推荐文章于 2023-12-19 10:48:43 发布

NanBaBa.ningjie

最新推荐文章于 2023-12-19 10:48:43 发布

阅读量285

点赞数 1

文章标签：服务器 servlet java

本文链接：https://blog.csdn.net/TDtuohai/article/details/126694731

版权

token介绍
Token 的中文意思是"令牌"。主要用来身份验证。比传统的身份验证方法，Token 有扩展性强，安全性高的特点，非常适合用在 Web 应用或者移动应用上。

它是服务端生成的字符串，作为客户端进行请求的一个标识。

token出现的背景
以前，Web 基本上就是文档的浏览而已，每次请求都是一个新的HTTP协议，就是请求加响应，尤其是我不用记住是谁刚刚发了HTTP请求。

随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，面临一个问题，必须记住哪些人登录系统，也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，起初想出的办法就是给每一个人发一个唯一的sessionid(一个随机的字符串)，下次大家再向我发起HTTP请求的时候，把这个sessionid带着，这样我就能区分开谁是谁了。

每个人只需要保存自己的session id，而服务器要保存所有人的session id ！这对服务器说是一个巨大的开销，严重的限制了服务器扩展能力，比如说我用两个机器组成了一个集群，小F通过机器A登录了系统，那session id会保存在机器A上，假设小F的下一次请求被转发到机器B怎么办？机器B可没有小F的 session id啊。

那只好做session 的复制了，把session id 在服务器之间搬来搬去，快累死了。

于是有人就在思考，我为什么要保存这可恶的session id，只让每个客户端去保存多好？

可是如果不保存这些session id , 怎么验证客户端发给我的session id 的确是我生成的呢？如果不去验证，我们都不知道他们是不是合法登录的用户，那些不怀好意的家伙们就可以伪造session id , 为所欲为了。所以，关键点就是验证！

比如说，小F已经登录了系统，我给他发一个令牌(token)，里边包含了小F的 user id，下一次小F 再次通过Http 请求访问我的时候，把这个token 通过Http header 带过来

不过这和session id没有本质区别啊，任何人都可以可以伪造，所以我得想点儿办法，让别人伪造不了。

那就对数据做一个签名吧，比如说我用HMAC-SHA256 算法，加上一个只有我才知道的密钥，对数据做一个签名，把这个签名和数据一起作为token ，由于密钥别人不知道，就无法伪造token了。

这个token服务器不保存，当小F把这个token 给我发过来的时候，我再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和token 中的签名做个比较，如果相同，我就知道小F已经登录过了，并且可以直接取到小F的user id , 如果不相同，数据部分肯定被人篡改过，我就告诉发送者：对不起，没有认证。

解除了session id这个负担，可以说是无事一身轻，我的机器集群现在可以轻松地做水平扩展，用户访问量增大，直接加机器就行。这种无状态的感觉实在是太好了。

token对比session
这种基于token的认证方式相比传统的session认证方式更节约服务器资源，并且对移动端和分布式更加友好。其优点如下：

支持跨域访问：cookie是无法跨域的，而token由于没有用到cookie(前提是将token放到请求头中)，所以跨域后不会存在信息丢失问题
无状态：token机制在服务端不需要存储session信息，因为token自身包含了所有登录用户的信息，所以可以减轻服务端压力
更适用CDN：可以通过内容分发网络请求服务端的所有资料
更适用于移动端：当客户端是非浏览器平台时，cookie是不支持的，采用token认证方式会简单很多
无需考虑CSRF：由于不再依赖cookie，所以采用token认证方式不会发生CSRF，所以也就无需考虑CSRF的防御
JWT介绍
jwt是token的一种实现方式，它将用户信息加密到token里，服务器不保存任何用户信息。服务器通过使用保存的密钥验证token的正确性，只要正确即通过验证。

优点
简洁: 可以通过URL、POST参数或者在HTTP header发送，因为数据量小，传输速度也很快
自包含：负载中可以包含用户所需要的信息，避免了多次查询数据库
Token是以JSON加密的形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持
不需要在服务端保存会话信息，特别适用于分布式微服务
缺点
无法作废已颁布的令牌
不易应对数据过期

组成
JWT是由.分割的三部分组成

jwt token = base64 URL(头部) + "." +base64 URL(负载) + "." + base64 URL(签名)

Base64 URL是一种编码，不是加密方式，是可以解码的

头部（Header）
{
"alg": "HS256",
"typ": "JWT"
}
alg是签名用的算法，默认为HMAC SHA256（写为HS256），JWT默认也是推荐的算法

typ属性表示令牌的类型，JWT令牌统一写为JWT

负载（Payload）
JWT的主体内容部分，也是JSON，包含需要传递的数据

JWT指定七个默认字段供选择

iss：发行人
exp：到期时间
sub：主题
aud：用户
nbf：在此之前不可用
iat：发布时间
jti：JWT ID用于标识该JWT
除默认字段外，我们还可以自定义字段，一般会把包含用户信息的数据放到payload中，如下

{
"sub": "1234567890",
"userID": "123456",
"admin": true
}
JWT里不要存放敏感信息，因为base64 URL编码是可以解码的

签名（Signature）
首先，需要指定一个密钥(secretKey)，该密钥只存在服务器中，不能向用户公开公开，使用header中指定的签名算法默认情况下为HMAC SHA256）根据以下公式生成签名。

Signature = HS256(Base64(头部) + "." + Base64(负载) , secretKey)

jwt校验
header 和 payload可以直接利用base64 URL解码出原文。