021.前后端分离架构下JWT认证该怎么设计.md · 独立团二营营长张大彪/Architecture

# $021$.前后端分离架构下JWT认证该怎么设计?

***

## 目录

- [$021$.前后端分离架构下JWT认证该怎么设计?](#021前后端分离架构下jwt认证该怎么设计)
  - [目录](#目录)
  - [$1$.什么是 $JWT$](#1什么是-jwt)
  - [$2$.$JWT$ 的认证架构设计？](#2jwt-的认证架构设计)
    - [方案一：网关统一校验](#方案一网关统一校验)
    - [方案二：应用认证方案](#方案二应用认证方案)
    - [两种方案的优缺点](#两种方案的优缺点)

***

## $1$.什么是 $JWT$

> 按照职责分成前台的应用和后端的应用，后端应用主要体现了业务逻辑的部分，而前端应用主要进行比如页面的渲染，以及相应的数据的返回工作。后端的工作对外暴露的接口恐怕不是所有人都能访问的，很多接口只有在经过授权或者拥有相应角色的时候才能进行访问。针对这种权限控制我们该怎么设计呢？这就是我们要讲解的 $JWT$ 的应用场景了。

<div align=center>
    <img src="./img/021/Front-and-rear-end-separation-architecture.png">
    <p>前后端分离</p>
</div>

- $Json\ Web\ Token\ (JWT)$
- $JWT$ 是一个经过加密的，包含用户信息的且
- 具有有时效性的固定格式字符串。

> 如图是一个 $JWT$ 字符串。按照颜色标记的不同，他会分成三类。第一个是前面黄色的部分，我们称之为标头，中间绿色的部分是我们要传递的数据的主体，我们称之为载荷，最后蓝色的部分则是具体的前面。整体的字符串都是经过加密的，是无法直接观看的。

> 首先来看第一部分，在标头 $Header$ 部分，如果按照原文来说，就是指采用什么样的加密算法来对数据进行加密，这里使用 $HS256$ 这种加密算法，它主要就是用来说明如何进行加密的。而第二部分

<div align=center>
    <img src="./img/021/jwt-header.png">
    <p>JWT-Header</p>
</div>

> 第二部分载荷——$Payload$，其实就是在 $JWT$ 中要包含的自定义的信息，作为 $Payload$，通常用于包含用户的一些信息。比如说用户的编号、昵称，以及一些非敏感的数据，都可以放在这里来进行数据的传递。

<div align=center>
    <img src="./img/021/jwt-payload.png">
    <p>JWT-Payload</p>
</div>

> 第三部分是签名，所谓签名就是结合前面的 $Header$ 以及 $Payload$，首先对其进行 $base64$ 的编码，再结合后端服务器所持有的一个私钥进行相应的加密工作，通过这样的公式完成一个签名的工作。这个签名是用来进行数据校验的，只有我们传递的原始数据和附加的签名完全相同的情况下，我们才会认为这个 $JWT$ 是一个合规的，不是人为篡改的，或者造假的。

> 以上就是 $JWT$ 三部分的各个部分的描述，其实并不复杂。但是这里又衍生出一个问题，像刚才的这种规则我们自己需要写吗？不用的，作为 $JWT$，在各个语言都有了良好的支持，以我用了十几年的 $Java$ 为例，这里就提供了一个叫 $JJWT$ 的组件。它提供了作为 $JWT$ 的创建与校验的工作。$JWT$ 生成过程代码示例如下：

```java
// 私钥字符串
String key = "1234567890_1234567890_1234567890";
// 1.对密钥做BASE64编码
String base64 = new BASE64Encoder().encode(key.getBytes());
// 2.生成密钥对象，会根据base64长度自动选择相应的 HMAC 算法
SecretKey secretKey = Keys.hmacShaKeyFor(base64.getBytes());
// 3.利用JJWT生成Token
String data = "{\"UserId\":123}"; // 载荷数据
String jwt = Jwts.builder().setSubject(data).signWith(secretKey).compact();
System.out.println(jwt);
```

> $JWT$ 校验过程代码如下：

```java
String jwt = "eyJhbGciOiJIUz1NiJ9.eyJzdWIioiJ7XCJ1c2VySWRcIjoxMjN9In0.1p_VTN4"
// 私有
String key = "1234567890_123456789_123456789";
// 1.对密钥做BASE64编码
String base64 = new BASE64Encoder().encode(key.getBytes());
// 2.生成密钥对象，会根据base64长度自动选择相应的 HMAC 算法
SecretKey secretKey = Keys.hmacShaKeyFor(base64.getBytes());
// 3.验证Token
try {
  // 生成JWT解析器
  JwtParser parser = Jwts.parserBuilder().setSigningKey(secretKey).build();
  // 解析JWT
  Jws<Claims> claimsJws = parser.parseClaimsJws();
  // 得到载荷中的用户数据
  String subject = claimsJws.getBody().getSubject();
  System.out.println(subject);
} catch {
  // 所有关于Jwt校验的异常都继承自JwtException
  System.out.println("Jwt校验失败");
  e.printStackTrace();
}
```

## $2$.$JWT$ 的认证架构设计？

> 下面阐述 $JWT$ 如何在分布式架构下来进行一个用户认证的。

### 方案一：网关统一校验

> 如下图，作为客户端，无论是浏览器，还是 $app$ 的应用也好，如果要访问后台的某一个私密的接口的话，那就必须第一步要进行登录的操作。
>
> 登录要单独的构建出来一个认证中心的应用，认证中心的主要职责就是接收来自于客户端提交的用户名和密码的信息。然后根据用户名和密码，首先在用户表里来进行查询、校验是不是有这个用户、密码是不是正确。如果校验通过以后，之后就根据当前用户的信息再配合服务器本地持有的 $jwt$ 密钥去生成 $jwt$ 字符串。就是上面三部分构成的长字符串。

<div align=center>
    <img src="./img/021/Gateway-unified-verification.png">
    <p>网关统一校验</p>
</div>

> 登录成功后，从认证中心返回的数据结构如下。比如我们向用户认证中心发起了登录请求，请求通过以后，那么从服务器返回的数据结构就是下面的：其中包括服务器的状态码以及服务器返回的消息。除此以外，在 $data$ 的部分包含登录成功以后的用户的基本信息，以及对这些用户基本信息生成的 $JWT$ 字符串，会包含在 $token$ 这个属性中。作为这个完整的 $Json$ 被客户端浏览器或者 $App$ 接收到以后，保存到本地，浏览器可以保存在 $Cookie$ 或者 $LocalStorage$ 中，如果是 $App$ 的话可以把他存储到 $ios$ 或者 $Android$ 的存储空间中。
>
> 登录成功以后，浏览器和服务器再向后台某一个具体的接口进行提交的时候会把刚才收集到的 $JWT$ 的字符串附加在请求头或者 $Cookie$ 中，向后台的应用网关进行发送。这里后台的应用网关就起到了一个拦截器的作用。在统一认证模式下，应用网关收到了来自客户端发来的 $Token$ 以后，它会立即向认证中心发起一个验签的操作。在验签的过程由认证中心去判断 $JWT$ 的信息是否有效，它有没有过期，以及验签完毕以后，会把之前放入其中的荷载提取出来进行返回，等于应用网关就获取到了当前登录用户的信息以及对应的权限数据。

```http
http://usercenter/login #认证中心用户认证（登录）地址
```

```json
{
  "code": "0",
  "message": "success",
  "data": {
    "user": {
      "userId": 1,
      "username": "zhangsan",
    },
    "token": "eyJhbGciOiJIUz1NiJ9.eyJzdWIioiJ7XCJ1c2VySWRcIjoxMjN9In0.1p_VTN4"
  }
}
```

> 如下是一个权限数据的示例。这是一个示意性的结构，实际应用时根据自己的项目需要进行调整。作为认证中心，验签后，返回的数据格式，主要包含两部分，第一部分是用户本身的这些信息，包括比如用户名密码，还有一些辅助的信息，另外还有就是权限的信息，比如说当前的角色是什么，它能够处理的这些权限的标识有哪些，例如 $addUser$、$delUser$ 什么的，这样的一组数据会由认证中心进行返回，然后再由应用网关转发给具体的业务模块。每一个业务模块在收到原始的业务参数之外，还可以接收到用户数据以及权限数据。然后业务模块再根据里面的权限数据来判断当前这个接口是否允许被执行，这就是统一认证的一个过程。

```json
{
  "code": "0",
  "message": "success",
  "data": {
    "user": { # 用户详细数据
      "userId": 1,
      "username": "zhangsan",
      "name": "张三",
      "grade": "normal",
      "age": 18,
      "idno": 130.......,
      ...
    },
    "authorization": { #权限数据
      "role": "admin",
      "permissions": [{"addUser", "delUser", "..."}]
    }
  }
}
```

### 方案二：应用认证方案

> 应用认证方案最大的区别是：浏览器和 $App$ 在获取到了 $JWT$ 以后，随着请求头发送给网关，此时网关是不做任何额外处理的，他会把 $JWT$ 原封不动的发给对应的业务模块，在业务模块中对 $JWT$ 进行验签以及校验的工作。而这个验签的过程还是通过认证中心来完成的。
>
> 统一认证和应用认证验签的时机是不一样的，这里就可能衍生出一个新问题，业务模块中控制器可能有几百个方法，其中有 $70\%$ 是需要验签的，$30\%$ 是不需要验签的。对于这 $70\%$ 的验签方法，我们如何来完成这个过程呢？

<div align=center>
    <img src="./img/021/Application-authentication-scheme.png">
    <p>应用认证方案</p>
</div>

> 这里给出了一个推荐的实现，如下。这里通过自定义注解实现，比如 $xxx()$ 是需要在执行前进行 $JWT$ 验签的，开发时只需要在需要验签的方法上添加自定义注解就可以自动完成验签的过程。验签成功则执行里面的代码，如果验签失败则直接放回异常信息。这里的 $@CheckJwt$ 是基于 $Spring\ AOP$ 的技术来进行实现的。

```java
@GetMapping("/xxx")
// 自定义注解，利用AOP做验签
@CheckJwt
public void xxx(){
  // Controller 代码
}
```

### 两种方案的优缺点

- 方案一：$JWT$ 校验无感知，验签过程无入侵，执行效率低，适用于低并发企业级应用

> 每一个发往后台的请求都要进行验签，而且验签的工作都是由网关来完成的。因此网关就成为了整个架构中的瓶颈所在，设计不好很可能拖垮整个应用。

- 方案二：控制更加灵活，有一定代码入侵，代码可以灵活控制，适用于追求性能互联网应用。

***

独立团二营营长张大彪/Architecture

简介

发行版

贡献者

近期动态

独立团二营营长张大彪/Architecture .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

独立团二营营长张大彪/Architecture