读懂JWT

最新推荐文章于 2024-03-28 18:06:04 发布

每天进步一奈奈

最新推荐文章于 2024-03-28 18:06:04 发布

阅读量2.1k

点赞数 1

分类专栏： jwt 文章标签： jwt

本文链接：https://blog.youkuaiyun.com/haogenmin/article/details/106903061

版权

jwt 专栏收录该内容

1 篇文章

订阅专栏

参考：

https://blog.youkuaiyun.com/xunileida/article/details/82961714

https://www.jianshu.com/p/99a458c62aa4

https://www.liqingbo.cn/docs/jwt/content/comprise.html

https://github.com/jwtk/jjwt

传统身份验证及问题

传统身份验证过程

1.用户向服务器发送用户名和密码。

2.验证服务器后，相关数据（如用户角色，登录时间等）将保存在当前会话中。

3.服务器向用户返回session_id，session信息都会写入到用户的Cookie。

4.用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。

5.服务器收到session_id并对比之前保存的数据，确认用户的身份。

问题

1、服务器压力问题

对于每一个用户的登录，我们都要为其存储一个session,并且还要设置一段时间内有效，那么对于短时间内有大量用户登录的系统而言，存储session则是一个非常大的开销，非常占用资源。

2、CSRF攻击问题

以上的验证步骤中，session_id是从cookie中自动发送到服务器的。那么问题来了，看一下过程：

用户访问A网站(http://www.aaa.com)，输入用户名密码
服务器验证通过，生成sessionid并返回给客户端存入cookie
用户在没有退出或者没有关闭A网站，cookie还未过期的情况下访问恶意网站B
B网站返回含有如下代码的html：

//假设A网站注销用户的url为：https://www.aaa.com/delete_user
<img src="https://www.aaa.com/delete_user" style="display:none;"/>

浏览器发起对A网站的请求，并带上A网站的cookie，注销了用户。

很明显发现，B网站在不知道A网站用户身份的前提下，实现了对用户A账户的操作。这就是CSRF攻击。

3、水平扩展问题

对于大用户群体的服务，肯定是要集群的，如果要实现在一台服务器上登录，在其他服务器也登陆，即单点登录，该怎么办？有朋友可能想到，把会话信息存储到外部存储中如redis。是的可以，但是我们知道cookie是无法跨域的。这是浏览器对cookie的一种保护机制。

这里我们说一下cookie的跨域限制及作用域。

跨域限制：

同源的定义

如果两个 URL 的 protocol、port (如果有指定的话)和 host 都相同的话，则这两个 URL 是同源。这个方案也被称为“协议/主机/端口元组”，或者直接是 “元组”。（“元组” 是指一组项目构成的整体，双重/三重/四重/五重/等的通用形式）。

下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:

URL	结果	原因
`http://store.company.com/dir2/other.html`	同源	只有路径不同
`http://store.company.com/dir/inner/another.html`	同源	只有路径不同
`https://store.company.com/secure.html`	失败	协议不同
`http://store.company.com:81/dir/etc.html`	失败	端口不同 ( `http://` 默认端口是80)
`http://news.company.com/dir/other.html`	失败	主机不同

浏览器的同源策略限制了，非同源的URL是不会主动传对方域设定的cookie的。

那么有的朋友又说了那我把session_id放在请求数据中，可以，那么设想一种糟糕的情形。你的外部存储宕机了……单点登录不就挂掉了吗？

cookie作用域：（了解一下，与本文关系不大）

摘自：https://blog.youkuaiyun.com/czhphp/article/details/65628977?utm_source=copy

我们在设置cookie的时候，是可以设置域范围的，那么这个域范围的设置会导致什么效果呢？

当我们给网站设置cookie时，大家有没有发现在网站的其他域名下也接收到了这些cookie。这些没用的cookie看似不占多少流量，但如果对一个日PV千万的站点来说，那浪费的资源就不是一点点了。因此在设置cookie时，对它的作用域一定要设置准确。

现在有如下3个域名，一个顶级域名、一个二级域名和一个三级域名：

① zydya.com
②blog.zyday.com
③one.blog.zyday.com

首先在①zyday.com域名下设置cookie，做四次测试，分别设置domain参数为空、'zyday.com'、'blog.zyday.com'与'one.blog.zyday.com'。
√表示该域名下能取到cookie，×表示不能取到cookie

domain参数	*zydya.com*	blog.zyday.com	one.blog.zyday.com
setcookie('name',1,time()+1)	√	√	√
setcookie('name',1,time()+1,'/','zyday.com')	√	√	√
setcookie('name',1,time() +1,'/','blog.zyday.com')	×	×	×
setcookie('name',1,time() +1,'/','one.blog.zyday.com')	×	×	×

当domain设置为空时，domain默认为当前域名，并且该域名下的子域名都可以接收到cookie。
但是domain参数设置其子域名时，所有域名就接收不到了，包括那个子域名。

然后在②blog.zyday.com域名下设置cookie，测试条件同上

domain参数	zydya.com	blog.zyday.com	one.blog.zyday.com
setcookie('name',1,time() +1)	×	√	√
setcookie('name',1,time()+1,'/','zyday.com')	√	√	√
setcookie('name',1,time()+1,'/','blog.zyday.com')	×	√	√
setcookie('name',1,time()+1,'/',one.blog.zyday.com')	×	×	×

看第二行，domain参数是zyday.com，是blog.zyday.com的父域名，那么zyday.com下所有子域名(包括zyday.com、blog.zyday.com、one.blog.zyday.com)都能接收到cookie。
当domain为自身域名时，那么其父域名受影响，其本身与其子域名可以接收到cookie。
而设置其子域名或其他域名时，所有域名都接收不到cookie了。

最后在③one.blog.zyday.com域名下设置cookie

domain参数	zydya.com	blog.zyday.com	one.blog.zyday.com
setcookie('name',1,time() +1)	×	×	√
setcookie('name',1,time()+1,'/','zyday.com')	√	√	√
setcookie('name',1,time()+1,'/','blog.zyday.com')	×	√	√
setcookie('name',1,time()+1,'/',one.blog.zyday.com')	×	×	√

第三个测试得出的结论在上面已经总结了。再看一遍，这里就不多解释了。

domain的设置，有两点要注意：

1.在setcookie中省略domain参数，那么domain默认为当前域名。

2.domain参数可以设置父域名以及自身，但不能设置其它域名，包括子域名，否则cookie不起作用。

那么cookie的作用域：

cookie的作用域是domain本身以及domain下的所有子域名。

好的，那么问题有了，怎么解决呢？就是文章标题了JWT。

JWT是什么？

JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JWT的鉴权机制

我们试想这样一种机制，用户的会话信息我不存在服务器上面，存在客户端上面，这样一来减轻了服务器的压力，而来，当我们扩展搭集群的时候，直接让客户端带着自己的信息去访问，不就不需要共享session了吗？

有朋友有疑问了，那么我自己随便捏造一个用户信息，岂不是就可以访问甚至修改你的服务了吗？是的，因此这个信息有点猫腻，我们这个用户信息是服务器给客户端的，有我服务器的签名（其实就是加密）那么你信息来了，我要看你的信息是不是我给你的，是我给你的我就解密成功，不是我给你的我就解密失败，那你自然不能访问。

还有朋友说了，那你这个信息放在哪里呢？

cookie或者localStorage里面。

那不是还有CSRF攻击的隐患。

是的，那我们在服务器不解析cookie,我们把cookie或者localStorage的信息放在请求头里面去例如：

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

我们解析请求头。

这样以上的问题就解决了，并且我们再生成token的时候应该设置token适当的有效期，这样更加安全。

鉴权流程：

用户使用用户名密码来请求服务器
服务器进行验证用户的信息
服务器通过验证发送给用户一个token
客户端存储token，并在每次请求时附送上这个token值
服务端验证token值，并返回数据

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

JWT的结构

一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。字符之间通过"."分隔符分为三个子串。这三个子串表示其三部分的结构。

JWT头

JWT头部分是一个描述JWT元数据的JSON对象，通常如下所示。

{

"alg": "HS256",

"typ": "JWT"

}

在上面的代码中，alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256）；typ属性表示令牌的类型，JWT令牌统一写为JWT。

最后，使用base64UrlEncode编码方式将上述JSON对象转换为字符串保存。如下：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

有效载荷：

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分。

标准中注册的声明（建议但不强制使用）

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token。

公共的声明

公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.

私有的声明

私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64UrlEncode是一种编码并不是加密，意味着该部分信息可以归类为明文信息。

这个指的就是自定义的claim。比如前面那个结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于：JWT规定的claim，JWT的接收方在拿到JWT之后，都知道怎么对这些标准的claim进行验证(还不知道是否能够验证)；而private claims不会验证，除非明确告诉接收方要对这些claim进行验证以及规则才行。

定义一个payload:

{"sub":"1234567890","name":"John Doe","admin":true}

然后将其进行base64UrlEncode编码，得到JWT的第二部分。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

签证（signature）

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

header (Base64 URL后的)
payload (Base64 URL后的)
secret

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

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Base64URL算法

如前所述，JWT头和有效载荷序列化的算法都用到了Base64URL。该算法和常见Base64算法类似，稍有差别。

作为令牌的JWT可以放在URL中（例如api.example/?token=xxx）。 Base64中用的三个字符是"+"，"/"和"="，由于在URL中有特殊含义，因此Base64URL中对他们做了替换："="去掉，"+"用"-"替换，"/"用"_"替换，这就是Base64URL算法

注意事项

1、secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

2、JWT前两部分是Base64URL编码的，也就意味着是明文的，里面不应该包含敏感信息。最后一部分是加密的，但是其实是对前面两部分做一个指纹，仅仅只是用于验证令牌并防止前两部分被串改，并不能保证你在载荷中的信息不会被人解析到。如果真要在载荷中增加私密信息，使用HTTPS协议，或者更进一步的自己在服务器端再加密一层，不过会增加服务器的负荷。

3、签证一旦泄露，任何人都可使用，因此要适当的设置过期时间，不宜过长，一般web登录设置30分钟左右为宜。

Java中的JWT实现

        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt-api</artifactId>
            <version>0.11.2</version>
        </dependency>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt-impl</artifactId>
            <version>0.11.2</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt-jackson</artifactId> <!-- or jjwt-gson if Gson is preferred -->
            <version>0.11.2</version>
            <scope>runtime</scope>
        </dependency>

package com.haogenmin.demoa1.manager;

import com.haogenmin.model.User;
import io.jsonwebtoken.*;
import io.jsonwebtoken.io.Decoders;
import io.jsonwebtoken.security.Keys;

import javax.crypto.SecretKey;
import java.util.Date;
import java.util.UUID;

/**
 * @author ：HaoGenmin
 * @Title :UserSessionManager
 * @date ：Created in 2020/6/22 13:58
 * @description：
 */
public class UserSessionManager {
    private String secretString = "IiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRGTY3ODkwIiwibmFtZSI6I";
    private long expiredMinute = 30; //token超时时间30分钟
    private UserSessionManager() {}

    private static UserSessionManager userSessionManager = new UserSessionManager();
    public static UserSessionManager getInstance() {
        return userSessionManager;
    }

    /**
     *
     * @param user  用户
     * @return java.lang.String
     * @author Hao Genmin
     * @description: 根据用户信息生成token
     * @date 2020/6/22 14:24
     */
    public String generateToken(User user) {
        //选择签证的加密算法，如果不制定默认HS256
        SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;

        // 把秘钥转换为BASE64URL编码的byte[],或者使用库函数生成一个key
        SecretKey key = Keys.hmacShaKeyFor(Decoders.BASE64URL.decode(secretString));
        //例如 SecretKey key = Keys.secretKeyFor(signatureAlgorithm);


        // 当然也可以选择其他编码或者不编码
        // BASE64编码
        //SecretKey key = Keys.hmacShaKeyFor(Decoders.BASE64.decode(secretString));
        // 不编码直接转为byte[]
        //SecretKey key = Keys.hmacShaKeyFor(secretString.getBytes(StandardCharsets.UTF_8));

        // 获取创建token的时间
        Date now = new Date();

        // 获取超时时间
        Date exp = new Date(now.getTime() + expiredMinute * 60 * 1000);

        String jws = Jwts.builder()
                .setIssuer("me") // 发行方声明，可选
                .setSubject("web") // 发行主体声明，可选
                .setAudience(String.valueOf(user.getId())) //给谁发行的签证声明，可选
                .setExpiration(exp) //签证过期时间声明，可选
                .setNotBefore(now) // 早于这个时间不可用声明，可选
                .setIssuedAt(now) // 签发时间声明，可选
                .setId(String.valueOf(UUID.randomUUID())) //设置为宜id，可选
                .claim("name",user.getName()) //自定义声明，可选
                .signWith(key,signatureAlgorithm)//加密
                .compact();
        return jws;
    }

    public boolean authentication(String jws) {
        SecretKey key = Keys.hmacShaKeyFor(Decoders.BASE64URL.decode(secretString));
        Jws<Claims> claims;
        try {
            claims = Jwts.parserBuilder()
                    .setSigningKey(key) //秘钥，如果使用非对称加密，这里应该用PublicKey
                    .build()
                    .parseClaimsJws(jws);
            /**
             * 处理claims
             */
            System.out.println(claims);
        } catch (JwtException ex) {
            return false;
        }
        return true;
    }
}

获得jws之后可以存在cookie中，之后请求放入请求头里面。