JSON Web Token
JWT是JSON Web Token的缩写 它是一种开源标准(RFC 7519)
用来定义通信双方如何安全地交换信息的格式。
JWT之所以叫JSON Web Token 是因为其头部和载荷在编码之前都是JSON格式的数据
JWT是一种标准 它有很多的实现方案
比如jwt-auth是专门为php框架laravel打造
jwt-auth
JWT规定以JSON的格式传递信息 负载payload的数据格式是JSON
通常使用base64编码
JWT是自包含的 Token本身携带了验证信息
不需要借助其他工具就可以知道一个Token是否有效 以及载荷信息
JWT的某些实现比如黑名单机制 Token刷新等增强功能 可能也需要借助其他工具 但是这并不违背自包含特性
JWT的结构
JWT结构
上图可以直观的看出JWT的结构 三种颜色代表三个部分
头部、载荷、签名。
头部
头部本身是JSON格式的,注意这里说的是编码之前的格式。头部包括两个字段,token的类型和加密算法。注意这里说的加密算法是签名的加密算法,不是头部的加密算法,也不是载荷的加密算法。实际上头部并没有经过加密,只是通过base64编码成字符串。
载荷
载荷也是JSON格式的,经过base64编码成字符串。上图例子中可以看到有sub,name,iat三个字段,实际上你可以放更多的信息,只要你需要,前提是JSON格式。
下面这些字段是标准定一个的字段,用来确保jwt有效工作的。
iss
Issuer的简写,代表token的颁发者。
sub
Subject的简写,代表token的主题。
aud
Audience的简写,代表token的接收目标。
exp
Expiration Time的简写,代表token的过期时间,时间戳格式。
nbf
Not Before的简写,代表token在这个时间之前不能被处理,主要是纠正服务器时间偏差。
iat
Issued At的简写,代表token的颁发时间。
jti
JWT ID的简写,代表token的id,通常当不同用户认证的时候,他们的token的jti是不同的。
以上字段都是RFC 7519标准确定的字段,通常由具体的实现框架来处理,具体的使用者不需要关心。
注意,除了以上标准定义的字段,用户可以自由添加需要的信息,通常我们会把全局的、经常使用的、安全要求不高的信息写入载荷,比如用户ID、用户名等信息。
JWT认证流程
用户使用账号和密码登录,调用后端登录接口;
后端登录程序生成jwt(注意这里小写指的是具体的token),这一步通常是由jwt插件完成的,我们只需要配置jwt加密密钥、token刷新时间、token有效时间;
后端返回jwt给前端;
前端之后的请求直接带上token即可,只要在token的有效期内;
后端收到前端的请求,会验证token的合法性、有效性,验证通过之后处理请求;
后端发送响应给前端。
JWT常见误区
JWT是不安全的,因为使用base64编码。这种理解是错误的,头部和载荷确实使用了base64编码,作用是编码而非加密,就是这么设计的,便于前端解码获取信息,所以头部和载荷不要存放保密信息。
JWT是自包含,不需要借助数据库和缓存。这种理解是错误的,当需要高级功能,比如token刷新、黑名单、多人共享账号等,还是需要借助缓存和数据库。
获取头部和载荷信息之后可以修改或者伪造token。这是不可能的,即使头部和载荷的信息完全一样,但是加密的私钥不对,签名也是不对的,后端验证也没法通过。
相关文章
- 【技术种草】cdn+轻量服务器+hugo=让博客“云原生”一下
- CLB运维&运营最佳实践 ---访问日志大洞察
- vnc方式登陆服务器
- 轻松学排序算法:眼睛直观感受几种常用排序算法
- 十二个经典的大数据项目
- 为什么使用 CDN 内容分发网络?
- 大数据——大数据默认端口号列表
- Weld 1.1.5.Final,JSR-299 的框架
- JavaFX 2012:彻底开源
- 提升as3程序性能的十大要点
- 通过凸面几何学进行独立于边际的在线多类学习
- 利用行动影响的规律性和部分已知的模型进行离线强化学习
- ModelLight:基于模型的交通信号控制的元强化学习
- 浅谈Visual Source Safe项目分支
- 基于先验知识的递归卡尔曼滤波的代理人联合状态和输入估计
- 结合网络结构和非线性恢复来提高声誉评估的性能
- 最佳实践丨云开发CloudBase多环境管理实践
- TimeVAE:用于生成多变量时间序列的变异自动编码器
- 具有线性阈值激活的神经网络:结构和算法
- 内网渗透之横向移动 -- 从域外向域内进行密码喷洒攻击