目录
一, JWT 简介
二, JWT 认证和 session 认证的区别
三, JWT 认证流程
四, JWT 组成
五, JWT 使用场景
一, JWT 简介
JSON web Token(JWT)是一个开放的标准(RFC 7519), 它定义了一个紧凑且自包含的方式, 用于在各方之间作为 JSON 对象安全地传输信息. 由于此信息是经过数字签名的, 因此可以被验证和信任.
更多信息可以查看官网: https://jwt.io/introduction/
二, JWT 认证和 session 认证的区别
session 认证
http 协议是一种无状态的协议, 而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证, 那么下一次请求时, 用户还要再一次进行用户认证才行, 因为根据 http 协议, 我们并不能知道是哪个用户发送的请求, 所以为了让我们的应用能识别是哪个用户发出的, 我们只能在服务器存储一份用户登陆的信息, 这份登陆信息会在响应时传递给浏览器, 告诉其保存为 cookie, 以便下次请求时发送给我们的应用, 这样我们的应用个就能识别请求来自哪个用户了, 这就是传统的基于 sessino 认证.
JWT 认证
基于 token 的鉴权机制类似于 http 协议也是无状态的, 它不需要在服务端去保留用户的认证信息或会话信息. 这也就意味着 JWT 认证机制的应用不需要去考虑用户在哪一台服务器登录了, 这就为应用的扩展提供了便利.
三, JWT 认证流程
认证流程如下:
用户使用账号和密码发出 post 请求;
服务器使用私钥创建一个 jwt;
服务器返回这个 jwt 给浏览器;
浏览器将该 jwt 串在请求头中像服务器发送请求;
服务器验证该 jwt;
返回响应的资源给浏览器.
四, JWT 组成
先来看一张 JWT 的信息的截图:
从上图可以看到, JWT 含有三部分: 头部(header), 载荷(payload), 签名(signature).
头部(header)
JWT 的头部有两部分信息:
声明类型, 这里是 JWT
声明加密的算法, 通常直接使用 HMAC SHA256
头部示例如下:
- {
- "alg": "HS256",
- "typ": "JWT"
- }
头部一般使用 base64 加密, 加密后密文: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
载荷(payload)
该部分一般存放一些有效的信息. JWT 的标准定义包含五个字段:
iss: 该 JWT 的签发者
sub: 该 JWT 所面向的用户
aud: 接收该 JWT 的一方
exp(expires): 什么时候过期, 这里是一个 Unix 时间戳
iat(issued at): 在什么时候签发的
载荷示例如下:
- {
- "sub": "1234567890",
- "name": "Java 碎碎念",
- "iat": 1516239022
- }
签名(signature)
前面两部分都是使用 Base64 进行编码的, 即前端可以解开知道里面的信息. signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥, 然后使用 header 中指定的签名算法 (HS256) 进行签名. 签名的作用是保证 JWT 没有被篡改过.
三个部分通过. 连接在一起就是我们的 JWT 了, 所以我们生成的 JWT 如下:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphdmHnoo7noo7lv7UiLCJpYXQiOjE1MTYyMzkwMjJ9.LLJIkhJs6SVYlzn3n8fThQmhGutjTDI3RURTLtHV4ls
注意: 密钥就是用来进行 JWT 的签发和 JWT 的验证, 所以, 它就是你服务端的私钥, 在任何场景都不应该泄露出去.
五, JWT 使用场景
JWT 主要使用场景如下:
授权
这是 JWT 使用最多的场景, 一旦用户登录, 每个后续的请求将包括 JWT, 从而允许用户访问该令牌允许的路由, 服务和资源.
信息交换: JSON
JWT 可以用在各方之间安全地传输信息, 因为 JWT 可以进行签名, 所以您可以确定发件人是他们所说的人. 另外, 由于签名是使用标头和有效负载计算的, 因此您还可以验证内容是否未被篡改.
到此 JWT 的基础和认证原理已经讲完了, 下一篇文章将介绍下 SpringBoot 中整合 JWT, 敬请期待哦.
来源: https://www.cnblogs.com/haha12/p/11796456.html