JWT:Json Web Token,是基于Json的一个公开规范,这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。、
是一种开发的行业标准RFC 7519,用于安全的表示双方之间的声明。目前,jwt广泛的用在系统的用户认证方面,特别是前后端分离项目。
他的两大使用场景是:认证和数据交换
使用起来就是,由服务端根据规范生成一个令牌(token),并且发放给客户端。此时客户端请求服务端的时候就可以携带者令牌,以令牌来证明自己的身份信息。
作用:类似session保持登录状态 的办法,通过token来代表用户身份。
在项目开发中,一般回按照下图所示的过程进行认证,即:用户登陆成功之后,服务端给用户浏览器返回一个token,以后用户浏览器要携带token再去向服务端发送请求,服务端校验token的合法性,合法则给用户看数据,否则,返回一些错误信息。
传统token方式和jwt在认证方面有什么差异?
传统token方式
用户登陆成功后,服务器生成一个随机token给用户,并且在服务端(数据库或缓存)中保留一份token,以后用户再来访问时需要携带token,服务端接收到token】之后,去数据库或缓存中进行校验token是否超时,是否合法。
jwt方式:
用户登陆成功后,服务端通过jwt生成一个随机token给用户(服务端无需保留token),以后用户在来访问时需要携带token,服务端接受到token之后,通过jwt对token进行校验是否超时,是否合法。
jwt生成的token格式如下,即:由 .
连接的三段字符串组成。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
JWT 的三个部分依次如下。
- Header(头部)
- Payload(负载)
- Signature(签名)
写成一行,就是下面的样子。
Header.Payload.Signature
Header 部分是一个 JSON 对象,描述 JWT 的元数据,通常是下面的样子。
{
"alg": "HS256",
"typ": "JWT"
}
上面代码中,alg
属性表示签名的算法(algorithm),默认是 HMACSHA256(写成 HS256);
typ
属性表示这个令牌(token)的类型(type)。
最后,将上面的 JSON 对象使用 Base64URL 算法(详见后文)转成字符串。
Payload 部分也是一个 JSON 对象,用来存放实际需要传递的数据。JWT 规定了7个官方字段,供选用。
- iss (issuer):签发人
- exp (expiration time):过期时间
- sub (subject):主题
- aud (audience):受众
- nbf (Not Before):生效时间
- iat (Issued At):签发时间
- jti (JWT ID):编号
除了官方字段,你还可以在这个部分定义私有字段,下面就是一个例子。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
注意,JWT 默认是不加密的,任何人都可以读到,所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。
Signature 部分是对前两部分的签名,防止数据篡改。
首先,需要指定一个密钥(secret)。这个密钥只有服务器才知道,不能泄露给用户。然后,使用 Header 里面指定的签名算法(默认是 HMACSHA256),按照下面的公式产生签名。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
算出签名以后,把 Header、Payload、Signature 三个部分拼成一个字符串,每个部分之间用"点"(.
)分隔,就可以返回给用户。
前面提到,Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似,但有一些小的不同。
JWT 作为一个令牌(token),有些场合可能会放到 URL(比如 api.example.com/?token=xxx)。Base64 有三个字符+
、/
和=
,在 URL 里面有特殊含义,
所以要被替换掉:=
被省略、+
替换成-
,/
替换成_
。这就是 Base64URL 算法。
一般在认证成功后,把jwt生成的token返回给用户,以后用户再次访问时需要携带token,此时要对token进行超时
及合法性
校验。
获取token之后,回按照一下步骤进行校验:
将token分割成header
、payload
、 signature 三部分
jwt_token="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
JwtUtils : 生成、校验jwt的工具类
package com.example.demo.utils;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.util.Base64;
// jwt生成、校验工具类
public class JwtUtils {
/* 默认head */
public static final String DEFAULT_HEADER = "{\"alg\": \"HS256\",\"typ\": \"JWT\"}";
/* HmacSHA256 加密算法 秘钥 */
public static final String SECRET = "12345";
/* token有效时间 1天 */
public static final long EXPIRE_TIME = 1000*60*60*24;
/* token在header中的名字 */
public static final String HEADER_TOKEN_NAME = "Authorization";
/** Base64URL 编码 */
public static String encode(String input) {
return Base64.getUrlEncoder().encodeToString(input.getBytes());
}
/** Base64URL 解码 */
public static String decode(String input) {
return new String(Base64.getUrlDecoder().decode(input));
}
/**
* signature 签名(即:对 header、payload进行加密)
* HmacSHA256 加密算法
* @param data 要加密的数据
* @param secret 秘钥
*/
public static String HMACSHA256(String data, String secret) throws Exception {
Mac sha256_HMAC = Mac.getInstance("HmacSHA256");
SecretKeySpec secret_key = new SecretKeySpec(secret.getBytes("UTF-8"), "HmacSHA256");
sha256_HMAC.init(secret_key);
byte[] array = sha256_HMAC.doFinal(data.getBytes("UTF-8"));
StringBuilder sb = new StringBuilder();
for (byte item : array) {
sb.append(Integer.toHexString((item & 0xFF) | 0x100), 1, 3);
}
return sb.toString().toUpperCase();
}
/** 获取签名 */
public static String getSignature(String payload) throws Exception {
return HMACSHA256(encode(DEFAULT_HEADER)+"."+encode(payload),SECRET);
}
/**
* 验证jwt,正确返回载体数据,错误返回null
* @param jwt
*/
public static String checkJwt(String jwt) throws Exception {
String[] jwts = jwt.split("\\.");
/* 验证签名 */
if (!HMACSHA256(jwts[0]+"."+jwts[1],SECRET).equals(jwts[2])){
return null;
}
/* 验证头部信息 */
if (!jwts[0].equals(encode(DEFAULT_HEADER))){
return null;
}
return decode(jwts[1]);
}
}
jwt_token
对第一部分header_segment
进行base64url解密,得到header
对第二部分payload_segment进行base64url解密,得到payload
对第三部分crypto_segment进行base64url解密,得到signature
对第三部分signature
部分数据进行合法性校验
signing_input
HS256
sign_input
进行加密,将得到的结果和signature
密文进行比较客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以储存在 localStorage。
此后,客户端每次与服务器通信,都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送,但是这样不能跨域,所以更好的做法是放在 HTTP 请求的头信息Authorization
字段里面。
Authorization: Bearer
另一种做法是,跨域的时候,JWT 就放在 POST 请求的数据体里面。
token 有效期一般都建议设置的不太长,那么 token 过期后如何认证,如何实现动态刷新 token,避免用户经常需要重新登录?
我们先来看看在 Session 认证中一般的做法:假如 session 的有效期30分钟,如果 30 分钟内用户有访问,就把 session 有效期被延长30分钟。
(1)JWT 默认是不加密,但也是可以加密的。生成原始 Token 以后,可以用密钥再加密一次。
(2)JWT 不加密的情况下,不能将秘密数据写入 JWT。
(3)JWT 不仅可以用于认证,也可以用于交换信息。有效使用 JWT,可以降低服务器查询数据库的次数。
(4)JWT 的最大缺点是,由于服务器不保存 session 状态,因此无法在使用过程中废止某个 token,或者更改 token 的权限。也就是说,一旦 JWT 签发了,在到期之前就会始终有效,除非服务器部署额外的逻辑。
(5)JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。
(6)为了减少盗用,JWT 不应该使用 HTTP 协议明码传输,要使用 HTTPS 协议传输。
深入了解jwt方案的优缺点