南昌网络营销网站,wordpress 全站不刷新,wordpress hexo,申请域名的流程在实际项目中一般会使用jwt鉴权方式。
JWT知识点
jwt#xff0c;全称json web token #xff0c;JSON Web令牌是一种开放的行业标准RFC 7519方法#xff0c;用于在两方安全地表示声明。具体网上有许多文章介绍#xff0c;这里做简单的使用。
1.数据结构
JSON Web Token…在实际项目中一般会使用jwt鉴权方式。
JWT知识点
jwt全称json web token JSON Web令牌是一种开放的行业标准RFC 7519方法用于·在两方安全地表示声明。具体网上有许多文章介绍这里做简单的使用。
1.数据结构
JSON Web Token 由三部曲组成他们之间用圆点 .进行分割一个标准的JWT形如xxx.yyy.zzz
HeaderPayloadSignature
1.1 header
头部由两部分组成;token的类型 JWT和算法名称HMAC 、SHA256、RSA......。
实例
{
alg: HS256
typ: JWT
}然后通过Base64对这个JSON编码就得到JWT得第一部分 1.2Payload
第二部分具体得实体可以写入自定义的数据信息有三种类型
Registered claims 这里有一组预定义的声明他们不是强制的但是推荐。如;iss(issuer签发者)expexpiration time 有效期subsubjectaudaudience等。public claims可以随意定义。private claims 用于在同意使用它们的各方之间共享信息并且不是注册的或者公开的声明
实例
{
iss: 加油,
exp: 182309645,
uname: 妮甲
}
对payload进行Base64编码就得到JWT的第二部分 1.3 Signature
为了得到签名部分你必须有编过码的header、编过码的payload、一个密钥签名算法是header中指定的那个然后对他们签名即可 签名是用于验证消息在传递过程中有没有被更改并且对于使用私钥签名的token它还可以验证JWT的发送方式是否为它所称的发送方式。
1.4具体实例
下面给出一个基于java-jwt生成的具体实例
public static void main(String[] args){String token JWT.create().withIssuer(加油).withExpiresAt(new Date(System.currentTimeMillis() 86400_000)).withPayload(MapUtils.create(uname , 妮甲 )) .sign(Alogorithm.HMAC256(helloWorld));System.out.println(token); } 技术派的应用
1.通过jwt鉴权方案 JWT鉴权流程
一个简单的基于jwt的身份验证方案如下图 基本流程分三步
1. 用户登录成功后后端将生成的jwt返回给前端然后前端将其保存在本地缓存2. 之后前端与后端的交互时都将jwt放在请求头中比如可以将其放在Http的身份认证的请求头AUthorization 也可以通过自定义的请求头来传递3. 后端接收到用户的请求从请求头中获取jwt然后进行校验通过后才相应相关的接口否则表示未登录。 说明项目采用session的方案将jwt写入到coolik中 2. jwt的使用
接下来看在技术派中的实际使用场景核心逻辑在
我们直接在之前session的基础上进行优化这里主要借助开源项目java-jwt来实现JWT的生成管理 生成JWT的实现 我们定义了签发者、有效期指定了签名算法然后实体类中携带两个信息 s:即之前生成的sesionId 我们借助自定义的traceId生成工具来生成唯一的会话idu用户userId
上面的实现中有几个通用的成员属性我们通过自定义的配置再启动项目时进行初始化避免后续的重复创建 自定义的jwt三个配置属性
paicoding:jwt:issuer: pai_coding #签发者secrethello_world #签名密钥expire: 2592000000 #jwt有效期 默认30天 jwt校验
用户每次请求时依然是沿用之前的session方式的校验逻辑在Filter层从请求头中获取Cookie找到对应的jwt然后尝试根据jwt获取对应的用户信息。 注意上面的实现即便是jwt校验通过了我们也依然从redis中查了一下判断是否有效
为啥这样设计
因为jwt本身无状态后端完全可以将redis这一层的存储都直接干掉纯依赖jwt的特性来完成身份鉴权但由于它的无状态后端减少存储压力是一个好处同样也是一个弊端后端失去了token的管控权如果我们希望提前失效某些用户身份则无法持续鉴于此这里依然保留了redis中存储jwt的方案。
3.实例体验
接下来我们实际体验一下线上运行技术派的jwt登录之后找到一个请求找到cookie中的f-session 我们解析一下这个是啥 站在用户的角度说实话你用session还是jwt没啥实质的感受差异那为啥还有两种不同的技术方案 session与jwt的对比
jwtsession前端存储通用的校验规则后端再获取jwt时校验是否有效前端存索引后端判断session是否有效验签不可篡改无签保障安全性有后端保障可存储非敏感信息如头像用户名 一般不存储业务信息 jwt生成时指定了有效期本身不支持续期以及提前失效后端控制有效期可提前失效或者自动续期通常以请求头方式传递通常以cookie方式传递可预防csrf攻击session-cookie方式存在csrf风险 注csrf攻击
如在网站页面上添加如下内容 然后当你访问此网站时结果发现你在技术派上登录的用户被注销啦 使用jwt预防csrf攻击的主要原理就是jwt通过请求头由js主动塞进去传递给后端而非cookie的方式从而避免csrf漏洞攻击技术派的jwt也是采用cookie进行携带jwt并不能解决上面这个个问题同样session方案也可以将sessionId通过请求头的方式传递按照这个说法也能避免csrf。
通常的方案由;
session-cookie方案
jwt-requestHeader方案
。
