1、什么是JWT?
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。
通俗的解释
jwt全称:Json Web Token,也就是通过Json格式作为web应用中的令牌,用于在各方之间安全的将信息作为json格式对象传输。在数据传输过程中还可以完成数据加密、签名等相关处理。
核心作用:安全验证和信息交换
安全验证:在我们的前后端分离系统的状态下,我们需要前端将携带令牌去访问后台,后台系统解签后进行对比,如果说jwt不正确,则不允许访问后台。
信息交换:在微服务时代,不同系统之间进行访问就可以使用jwt。
1、授权
- 这是jwt的常见方案,一旦用户登录,每个后续请求包括JWT,从而允许用户访问该令牌允许的路由,服务和资源。单点登录是当今广泛使用JWT的一项功能,因为他的开销很小,并且可以在不同域之间轻松使用。
2、信息交换
- jwt是在各方之间安全传输信息的好方法。因为可以对JWT进行签名,所以可以确保发件人是他们所说的人。此外,由于签名是使用标头和有效负载计算的,因此我们还可以验证内容是否遭到篡改。
2、为什么是JWT
我们先来看一下基于传统的Session认证
1、http本身是一种没有状态的协议,这就意味着如果用户向我们的应用提供了用户名和密码进行用户的认证,那么下一次请求时,用户还需要进行认证才可以,因为http请求,我们应用并不知道这个请求是由哪一个用户发出的请求,所以我们为了让应用可以识别是那个用户发出的请求我们就需要在服务器上存一份用户的登录的信息,这份登录信息会在响应时返回给浏览器,这个就是jseesionid,以后我们再次请求就携带这个参数,这样应用就知道是哪里进行发送请求的。
2、基于传统的session认证流程
3、暴露的问题
-1、每个用户都要访问一次服务器时都会保存一份信息到seesion,通常seesion是保存在内存中,如果我们的用户过多,那么这个非常占用服务器的资源,随着认证用户的增多,服务器开销会很大。
-2、刚才我们说了,信息会保存到内存中去,如果是分布式应用,原来在这个服务器上保存的信息换一台服务器就不管用了!在分布式的应用上,相应的限制了负载均衡的能力。这意味着限制了应用的扩展能力。
-3、安全问题:因为是基于cookie进行用户识别的,如果cookie被拿走,很容易被请求伪造攻击。
-4、在前后端分离的系统中,会更加痛苦!通常用户一次请求就要转发多次,如果seesion每次都要携带sessionid到服务器,s服务器还要查询用户信息。如果用户很多,这些信息存储在服务中,会带来很多负担。
好了,让我们再看看当下流行的jwt的认证方式。
1、认证流程
- 首先,前端通过web表单将自己的用户名和密码发送给后端的接口,这一般是一个post请求。建议是ssl加密传输,就是https。
- 后端验证完密码之后,将用户的id等其他信息作为JWT 的payload(负载),将其与头部分别进行Base64编码拼接后形成sign,如同xxxxx.yyyy.zzzz的形式
- 后端将jwt的字符串相应给前端页面,保存到localStage或者sessionStorage上,退出系统时删除即可。
- 前端每次请求时,将jwt放在Authorization位。
- 后端检查是否存在,如验证jwt的有效性。
2、优势
- 简洁
- 自包含,我们可以在jwt中存放一些不敏感信息,避免多次查询数据库。
- 由于toke是以加密的形式存放在客户端,所以jwt是可以跨语言的,原则上各种web都支持。
- 不需要保存在服务端,适用于微服务架构的系统,
3、JWT 的结构
组成:
- 标头(Header)
- 有效载荷(payload)
- 签名(sign)
- 标头通常由两部分组成,令牌的类型和所使用的签名算法,HMAC、SHA256或者RSA。他会使用base64编码组成jwt的第一部分。
{
"alg":"HS256",
"typ":"JWT"
}
// 值得注意的是这个typ就是type的缩写,简洁!
- 有效载荷(payload),包括声明。声明是有关实体,和其他数据的声明,也是由base64进行编码组成jwt的第二个部分。
{
"username":"szw",
"sub":"123",
"admin":true
}
// payload中不要存放敏感信息
- 签名(signature)
- 前两部分我们都是用base64进行编码的,即前端是可以解开知道里面的信息的,sign是需要使用编码后的header和payload以及我们提供的一个秘钥(salt),加上我们在header中指定的加密算法进行签名,签名的作用是保证jwt是没有被篡改过的。
作用?
最后一步的签名的过程,实际上就是对头部以及负载内容进行签名,如果头部以及负载的内容被人解开之后再进行篡改,最后加上之前的签名形成新的jwt时,就会出毛病,因为服务器会重新根据篡改后的前两个位置的信息判断签名,签名不一致是不行的。
4、创建第一个程序
4.1引入依赖
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>3.10.3</version>
</dependency>
4.2编写测试程序
class DemoApplicationTests {
private static final long EXPIRE_TIME = 60L * 60L * 1000L;
@Test
void contextLoads() {
Date date = new Date(System.currentTimeMillis() + EXPIRE_TIME);
// token
String token = JWT.create().withClaim("userid",21)
.withClaim("username","szw")
.withExpiresAt(date)
.sign(Algorithm.HMAC256("szwSign123!"));
System.out.println(token);
}
@Test
public void getTokenMessage(){
// 返回带有用于验证令牌签名的算法的{@link JWTVerifier}构建器。验证对象
JWTVerifier jwtVerifier = JWT.require(Algorithm.HMAC256("szwSign123!")).build();
// 使用构建起解析原来的token
DecodedJWT verify = jwtVerifier.verify("eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2MDMzNDU1MDIsInVzZXJpZCI6MjEsInVzZXJuYW1lIjoic3p3In0.MD0J9asVpn8efet4f-DJBS0Hyc3HCswX6_vT06e53Ng");
System.out.println(verify.getClaim("userid").asInt());
System.out.println(verify.getClaim("username").asString());
// 取出过期时间
System.out.println(verify.getExpiresAt());
}
}
常见的异常信息有:
- SignatureVerificationException 签名不一致
- AlgorithmMismatchException 算法不匹配
- 过期异常和失效payload异常
5封装工具类
由于jwt我们日后会经常使用到,所以我们可以将jwt经常使用的方法封装成一个工具类。
/**
* @author szw<szw0814 @ 1 6 3 . com> 2020/10/22
*/
public class JwtUtils {
private static final String sign = "ass12%w1!+-";
/**
*生成token的工具类
*/
public String getToken(Map<String,String> map){
// 获取日历对象
Calendar instance = Calendar.getInstance();
// 1周的时间
instance.add(Calendar.DAY_OF_WEEK,1);
// 创建jwt的builder
JWTCreator.Builder builder = JWT.create();
// 使用lambda表达式将map中的kv传进来
map.forEach((k,v) -> {
builder.withClaim(k,v);
});
String token = builder.withExpiresAt(instance.getTime())
.sign(Algorithm.HMAC256(sign));
return token;
}
/**
* 验证token
*/
public static DecodedJWT verifyToken(String token){
return JWT.require(Algorithm.HMAC256(sign)).build().verify(token);
}
}