JWT安全登录
官网:https://jwt.io/
一、JWT简介
1.什么是JWT
# 官网描述
- JSON Web Tokens are an open, industry standard [RFC 7519](https://tools.ietf.org/html/rfc7519) method for representing claims securely between two parties.
- JWT.IO allows you to decode, verify and generate JWT.
# 翻译
- JSON Web Token是一种开放的行业标准 RFC 7519 方法,用于安全地代表双方之间的索赔。
- Jwt.IO 允许您解码、验证和生成 JWT。
2.JWT能做什么
# 授权
- 这是使用JWT的最常见方案。一旦用户登录,每个后续请求将包括JWT,从而郧西用户访问该令牌允许的路由,服务和资源。但钱登录时当今广泛使用JWT的一项功能,它的凯西笑傲小并且可以再不同的域种轻松使用
# 信息交换
- JSON Web Token是在各方安全地传输信息地号方法。因为可以对JWT进行签名(例如,使用公钥/私钥对),所以您可以确保发件人是他们所说地人。此外,由于签名是使用表头和有效负载计算地,因此您还可以验证内容是否遭到篡改
3.为什么是JWT
基于传统地Session认证
# 认证方式
- 我们知道,http协议本省是一种无状态地协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,我们并不知道时哪个用户发出的请求,所以为了让我们为您的应用能识别时那个用户发出的请求,我们只能在服务器存储一份用户信息,这份登录信息会在响应式传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的引用,这样我们的应用就能识别请求来自哪个用户了,这就是传统基于session认证。
# 认证流程
客户端-->认证-->服务器session-->cookie
客户端-->cookie-->服务器session
# 暴露问题
- 每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存种,而随着认证用户的增多,服务端的开销会明显增大
- 用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意为着用户下次请求还必须徐要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,响应的限制了负载均衡的能力。这也意味着限制了应用的扩展能力。
- 因为是基于cookie来进行识别的,cookie如果被截获,用户就会很容易收到跨站请求伪造的攻击。
- 在前后端分离系统中,就更加痛苦
- 也就是说前后端分离在应用解耦后增加了部署复杂性。通常用户一次请求就要转发多次。如果用session,每次携带sessionid到服务器,服务器还要查询用户信息。同时如果用户很多,这些信息存储在服务器内存中,给服务器增加负端。还有就是CSRF(跨站伪造请求)攻击,session是基于cookie进行用户识别,cookie如果被截获,用户就会很容易受到跨站伪造请求的攻击。还有就是sessionid就是一个特征值,表达的信息不够丰富,不容易扩展。如果你后端应用是多节点部署,那么就需要实现session共享机制,不方便集群应用。
基于JWT认证
# 认证流程
- 首先,前端通过web表单将自己的用户名和密码发送到后端的接口,这一过程一般是一个Htto POST请求,建议的方式是通过SSL加密的传输(https协议),从而避免铭感信息被嗅探。
- 后端核对用户名和密码成功后,将用户名的id等其他信息作为JWT Payload(负载),将其与头部分别进行Base64编码拼接后签名,形成一个JWT,形成的JWT就是一个形同xxx.yyy.zzz的字符串[token(Header.payload.Singurater)]
- 后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回地结果保存在localStorage或sessionStorage上,退出登录时前端删除保存的JWT即可
- 前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)
- 前端检查是否存在,如存在验证JWT的有效性。例如,检查签名是否正确;检查Token是否过期;检查Token的接收是否是自己(可选)
- 验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作,返回响应结果
# JWT优势
- 简介(Compact):可以通过URL,POST参数或者在HTTP header发送。因为数据量小,传输速度也很块
- 自包含(Self-contained):负载中包含了所有用户所需要的信息,避免了多次查询数据库
- 因为Token是以JSON加密的形式保存在客户端的,所以JWT是跨语言的,原则上任何web形式都支持
- 不需要再服务端爆粗你会话信息,特别适合用于分布式微服务
二、JWT结构
# 令牌组成
- 标头(Header)
- 负载(Pyload)
- 签名(Signurater)
- token : String
- 因此,JWT通常如下所示:xxx.yyy.zzz Header.Payload.Signature
1.Header
- 表头通常由两部分组成:令牌的类型(即JWT)和所使用的签名算法,例如HMAC SHA256胡哦RSA。他会使用Base64编码组成JWT结构的第一部分。
- 注意:Base64是一种编码,也就是说,它时可以被翻译回原来的样子的。它并不是一种加密过程
{
"alg":"HS256",
"typ":"JWT"
}
2.Payload
- 令牌的第二部分是有效负载,其中包含声明。声明式有关实体(通常是用户)和其他的数据的声明。同样的,他会使用Base64编码组成JWT结构的第二部分
{
"sub":"123456789",
"name":"John Doe",
"admin":true
}
3.Signature
- 前面两部分都是使用Base64进行编码的,前端可以解开知道里面的信息。Signatue需要使用编码后的header和payload以及我们提供的一个密码,然后使用header中指定的签名算法(HS256)进行签名。签名的作用是保证JWT没有被篡改过
- 如:
- HMACSHA256(base64UrlEncode(header)+"."+base64Url(payload),secret)
# 签名的目的
- 最后一步签名的过程,实际上是对头部以及对头部以及负载内容进行签名,防止内容被串改。如果有人对头部以及负载的内容节码之后进行修改,在进行编码,最后加上之前的签名组合形成新的JWT的话,那么服务器端会判断出新的头部和负载形成的签名和JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名,在不知道服务端加密是用的密钥的话,得出来得签名也是不一样的
# 信息安全问题
- 在这里大家一定会问一个问题:Base64是一种编码,是可你的,那么我的信息就被暴露了嘛?
- 是的,所以在JWT中不应该在负载里面加入任何敏感数据。在上面的例子中,我们传输的是用户的UserID ,这个实际上不是什么敏感内容,一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中,那么怀有而已的第三方通过Base64解码就能很快地知道你的密码了。因此JWT适合用于向Web应用传递一些非铭感信息。JWT还经常用于设计用户认证和授权系统,设置实现Web应用的单点登录
# 组合
- 输出三个由点分隔的Base64-URL字符串,可以在HTML和HTTP环境中轻松传递这些字符串,与基于XML的标准(例如SAML)相比,它更紧凑
三、JWT的第一个程序
1.jwt依赖
<!--jwt-->
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>3.4.0</version>
</dependency>
2.生成token
/*
* JWT生成令牌
* */
@Test
void contextLoads() {
HashMap<String,Object> map = new HashMap<>();
Calendar instance = Calendar.getInstance();
instance.add(Calendar.SECOND,90);
//生成令牌
String token = JWT.create()
.withHeader(map)
.withClaim("username","张三")//设置自定义用户名
.withExpiresAt(instance.getTime())//设置过期时间
.sign(Algorithm.HMAC256("token!Q2W#E$RW"));//设置签名 保密 复杂
//输出令牌
System.out.println(token);
}
3.生成结果
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2MTc1Mzk2NDksInVzZXJuYW1lIjoi5byg5LiJIn0.0TwtZnZpDDte6FpWnxl4Oyzc1TFgKU6kmkvUBBJvr54
4.验签
/*
* JWT验签
* */
@Test
void test(){
//创建验证对象
JWTVerifier jwtVerifier = JWT.require(Algorithm.HMAC256("token!Q2W#E$RW")).build();
DecodedJWT verify = jwtVerifier.verify("eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2MTc1Mzk2NDksInVzZXJuYW1lIjoi5byg5LiJIn0.0TwtZnZpDDte6FpWnxl4Oyzc1TFgKU6kmkvUBBJvr54");
System.out.println(verify.getClaim("username").asString());
}
5.常见异常信息
- SignatureVeificationException 签名不一致异常
- TokenExpiredException 令牌过期异常
- AlgorithMismatchException 算法不匹配异常
- InvalidClaimException 失效的payload异常
四、JWT的工具类封装
JwtConstants
package com.simpleteen.utils;
/*
* Jwt常数
* */
public class JwtConstants {
/**
* 私钥
*/
public static final String JWT_SECRET_KEY = "token!Q2W#E$RW";
/**
* 过期时间:24小时
*/
public static final long EXPIRATION = 60 * 60 * 24L;
}
JwtUtils
package com.simpleteen.utils;
import com.auth0.jwt.JWT;
import com.auth0.jwt.JWTCreator;
import com.auth0.jwt.algorithms.Algorithm;
import com.auth0.jwt.interfaces.DecodedJWT;
import java.util.Date;
import java.util.Map;
/*
* Jwt工具类
* */
public class JwtUtils {
/*
* 生成token header。payload。signature
* */
public static String getToken(Map<String,String> map){
//定义过期时间
final Date createdDate = new Date();
final Date expirationDate = new Date(createdDate.getTime() + JwtConstants.EXPIRATION * 1000);
//创建jwt builder
JWTCreator.Builder builder = JWT.create();
//payload
map.forEach((k,v)->{
builder.withClaim(k,v);
});
//Signature
String token = builder.withExpiresAt(expirationDate)//设置过期时间
.sign(Algorithm.HMAC256(JwtConstants.JWT_SECRET_KEY));//设置签名 保密 复杂
//输出令牌
return token;
}
/*
* 验证token合法性,获取token信息
* */
public static DecodedJWT verify(String token){
return JWT.require(Algorithm.HMAC256(JwtConstants.JWT_SECRET_KEY)).build().verify(token);
}
}
五、SpringBoot整合JWT
这里就不再去讲解SpringBoot项目,毕竟是为了将JWT,而不是讲SpringBoot项目。我们可以再Controller里面使用getToken,然后验证的话Web项目可以在拦截器中使用verify或者分布式的项目可以在网关中使用verify。