Jwt简介

1、为什么使用JWT

基于Session的认证

• 基于Session的认证应该是最常用的一种认证机制了。用户登录认证成功后，将用户相关数据存储到Session中，单体应用架构中，默认Session会存储在应用服务器中，并且将Session ID返回到客户端,存储在浏览器的Cookie中。

• 但是在分布式架构下，Session存放于某个具体的应用服务器中自然就无法满足使用了,简单的可以通过Session复制或者Session粘滞的方案来解决。

• Session复制依赖于应用服务器，需要应用服务器有Session复制能力，不过现在大部分应用服务器如Tomcat、jBoss、 WebSphere 等都已经提供了这个能力。

• 除此之外, Session复制的一大缺陷在于当节点数比较多时，大量的Session数据复制会占用较多网络资源。Session 粘滞是通过负载均衡器,将统一用户的请求都分发到固定的服务器节点上，这样就保证了对某一用户而言 ，Session数据始终是正确的。不过这种方案依赖于负载均衡器，并且只能满足水平扩展的集群场景,无法满足应用分割后的分布式场景。

• 在微服务架构下，每个微服务拆分的粒度会很细,并且不只有用户和微服务打交道,更多还有微服务间的调用。这个时候上述两个方案都无法满足,就要求必须要将Session从应用服务器中剥离出来，存放在外部进行集中管理。可以是数据库，也可以是分布式缓存，如Memchached、Redis等。这是分布式Session方案。

• 在前后分离的情况下,后端只负责通过暴露的RestAPI提供数据,而页面的渲染、路由都由前端完成。由于REST是无状态的,因此也就不会采用Session记录会话状态。

基于Token的认证

随着Restu API,微服务的兴起,微服务集群中的每个服务，对外提供的都是Rest风格的接口，而Res风格的一个最重要的规范就是: 服务的无状态性，即:

• 服务端不保存任何客户端请求者状态信息

• 客户端的每次请求必须具备自描述信息通过这些信息识别客户端身份

基于Token认证的好处如下:

• 服务端无状态 :Token 机制在服务端不需要存储session信息，因为 Token自身包含了所有用户的相关信息。

• 性能较好 ，因为在验证 Token时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。支持移动设备。

• 支持跨程序调用，Cookie是不允许垮域访问的，而Token则不存在这个问题。

• 客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同台服务

2、什么是JWT

JWT (ISON WEB TOKEN)是一种用来在网络 上声明某种身份的令牌(TOKEN)，基于RFC7519标准定义的一种可以安全传输的ISON对象。它的特点是紧凑且自包含并且基于ISON，通过一些常用的算法对包含的主体信息进行加密,安全性很高。它通常有三个部分组成：头信息(Header)、消息体（Payload）、签名（signature）

3、基于JWT方式的认证流程

• 客户端调用登录接口(或者获取token接口)， 传入用户名密码。

• 服务端请求身份认证中心，确认用户名密码正确。

• 服务端创建JWT，返回给客户端。

• 客户端拿到JWT ,进行存储(可以存储在缓存中,也可以存储在数据库中,如果是浏览器，可以存储在Cookie中)在后续请求中,在HTTP请求头中加上JWT。

• 服务端校验JWT ,校验通过后，返回相关资源和数据。
  

在微服务架构下，通常有单独一个服务Auth去管理相关认证，为了安全不会直接让用户访问某个服务，会开放一个入口作为网关gateway，所有请求首先访问gateway，由gateway请求路由到各个服务，基本过程如下所示。

4、jWT的组成

• Header (头部) --base64编码的Json字符串

Header中用于存放签名的生成算法:

{
	'type': 'JWT', //声明类型
	'alg': ' RS256' //签名加密的算法
}

然后将头部进行base64加密 (该加密是可以对称解密的),构成了第一部分。

eyJ0exAioi JKV1Qi LCJhbGcioi JSUZI1NiJ9

● Payload (载荷) - - base64编码的Json字符串
Payload中用于存放用户名、token的生成时间和过期时间

//包括需要传递的用户信息:
{ 
	"iss": " admin"，
	"iat": 1600879172944,
	"exp": 1600879202944,
	"aud": "hello"，
	"sub": "uid" ,
	"name": "hello"
}

然后将其进行base64加密，得到wt的第二部分。

eyJuYW11Ijoi aGVsbG8iLCJ1 eHAioj E2MDA4NzkyMDN9

● Signature (签名)- – -使用指定算法，通过Header和Payload加盐计算的字符串
JWT的第三部分是一个签证信息 ，这个签证信息由三部分组成:

/根据头部alg算法与私有秘进行加密得到的签名字符串:2//这一段是最重要的敏感信息，只能在服务端解密:
HMACSHA256(
base64urTEncode(header) +”." +

base64Ur1Encode(payload) ,

SECREATE KEY

这个部分需要base64加密后的header和base64加密后的payload使用"."连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了JWT的第三部分。

将这三部分用"."连接成一个完整的字符串 ,构成了最终的JWT

eyJ0eXAioi JKV1Qi LCJhbGci0iJSUzI1NiJ9. eyJuYw1lIjoi aGVsbG8i LCJ1eHAiOj E2MDA4NzkyMDN9. ravqPpUpF_skUjN5Jo_ B0BRfgQg7 ZNPTdkVmvVW5rtxjA9btkvt0xf0rHi PgTDYDNSW4RmoHH-
XT_QVeqMPsILyy7aMgVu1YRKx1pxQkPhynrcQ09CxmGJf3WiUPJEoi1ZaeVACaZAkt1zcXfAEBp0uHKbEERWk1o -SIOh5OSjJV1aTB2ZQKRR2uPm55bwe_ _j1kwfefR0bZ5v25I4-T0ol1zV-6MTTW9nrZ3U7tBIRVJDNwVQ- 5_ _jzkQC1voxT-
ah0540I tAMcz7w2rVghBDR 5vqbKz9wo7PWudAo1uKOXRO5bCqev3wU6jvdw8-
kOGYs6cy1Fa2SpmeskinJ4SHQQ

5、jWT常见的签名算法

HS256(HMAC-SHA256)、RS256(RSA-SHA256)、 ES256(ECDSA-SHA256)

这三种算法都是一种消息签名算法，得到的都只是一段无法还原的签名。区别在于消息签名与签名验证需要的「key」 不同。

1.HS256使用同一个「secret key」进行签名与验证。一旦secret key泄漏,就毫无安全性可言了。因此HS256只适合集中式认证,签名和验证都必须由可信方进行。

2.RS256是使用RSA私钥进行签名,使用RSA公钥进行验证。公钥即使泄漏也毫无影响,只耍确保私钥安全就行。

• RS256可以将验证委托给其他应用,只要将公钥给他们就行。

3.ES256和RS256 -样,都使用私钥签名，公钥验证。算法速度上差距也不大,但是它的签名长度相对短很多(省流量) , 并且算法强度和RS256差不多。

对于单体应用而言, HS256和RS256的安全性没有多大差别。

而对于需要进行多方验证的微服务架构而言，显然RS256/ES256安全性更高。

只有用户微服务需要用RSA私钥生成JWT，其他微服务使用公钥即可进行签名验证，私钥得到了更好的保护。

6.JJWT依赖

jjwt是一个Java对jwt得支持库，我们使用这个库来创建、解码token；
JJWT是纯Java实现的，完全基于JWT、JWS、JWE RFC规范以及Apache 2.0许可条款下的开源实现。

<!--新版本-->
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.1</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.1</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId>        	
    <version>0.11.1</version>
    <scope>runtime</scope>
</dependency>
<!-- 开源软件 -->
<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-all</artifactId> 
    <version>5.3.3</version>
</dependency>