手把手教大家在 gRPC 中使用 JWT 完成身份校验

Posted _江南一点雨

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了手把手教大家在 gRPC 中使用 JWT 完成身份校验相关的知识，希望对你有一定的参考价值。

文章目录


上篇文章松哥和小伙伴们聊了在 gRPC 中如何使用拦截器，这些拦截器有服务端拦截器也有客户端拦截器，这些拦截器的一个重要使用场景，就是可以进行身份的校验。当客户端发起请求的时候，服务端通过拦截器进行身份校验，就知道这个请求是谁发起的了。今天松哥就来通过一个具体的案例，来和小伙伴们演示一下 gRPC 如何结合 JWT 进行身份校验。

1. JWT 介绍

1.1 无状态登录

1.1.1 什么是有状态

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如 Tomcat 中的 Session。例如登录：用户登录后，我们把用户的信息保存在服务端 session 中，并且给用户一个 cookie 值，记录对应的 session，然后下次请求，用户携带 cookie 值来（这一步有浏览器自动完成），我们就能识别到对应 session，从而找到用户的信息。这种方式目前来看最方便，但是也有一些缺陷，如下：

  • 服务端保存大量数据，增加服务端压力
  • 服务端保存用户状态，不支持集群化部署

1.1.2 什么是无状态

微服务集群中的每个服务，对外提供的都使用 RESTful 风格的接口。而 RESTful 风格的一个最重要的规范就是：服务的无状态性，即：

  • 服务端不保存任何客户端请求者信息
  • 客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份

那么这种无状态性有哪些好处呢？

  • 客户端请求不依赖服务端的信息，多次请求不需要必须访问到同一台服务器
  • 服务端的集群和状态对客户端透明
  • 服务端可以任意的迁移和伸缩（可以方便的进行集群化部署）
  • 减小服务端存储压力

1.2 如何实现无状态

无状态登录的流程：

  • 首先客户端发送账户名/密码到服务端进行认证
  • 认证通过后，服务端将用户信息加密并且编码成一个 token，返回给客户端
  • 以后客户端每次发送请求，都需要携带认证的 token
  • 服务端对客户端发送来的 token 进行解密，判断是否有效，并且获取用户登录信息

1.3 JWT

1.3.1 简介

JWT，全称是 Json Web Token， 是一种 JSON 风格的轻量级的授权和身份认证规范，可实现无状态、分布式的 Web 应用授权：

JWT 作为一种规范，并没有和某一种语言绑定在一起，常用的 Java 实现是 GitHub 上的开源项目 jjwt，地址如下：https://github.com/jwtk/jjwt

1.3.2 JWT数据格式

JWT 包含三部分数据：

  • Header：头部，通常头部有两部分信息：

    • 声明类型，这里是JWT
    • 加密算法，自定义

我们会对头部进行 Base64Url 编码（可解码），得到第一部分数据。

  • Payload：载荷，就是有效数据，在官方文档中(RFC7519)，这里给了7个示例信息：

    • iss (issuer)：表示签发人
    • exp (expiration time)：表示token过期时间
    • sub (subject)：主题
    • aud (audience)：受众
    • nbf (Not Before)：生效时间
    • iat (Issued At)：签发时间
    • jti (JWT ID)：编号

这部分也会采用 Base64Url 编码，得到第二部分数据。

  • Signature：签名，是整个数据的认证信息。一般根据前两步的数据，再加上服务的的密钥secret（密钥保存在服务端，不能泄露给客户端），通过 Header 中配置的加密算法生成。用于验证整个数据完整和可靠性。

生成的数据格式如下图：

注意，这里的数据通过 . 隔开成了三部分，分别对应前面提到的三部分，另外，这里数据是不换行的，图片换行只是为了展示方便而已。

1.3.3 JWT 交互流程

流程图：

步骤翻译：

  1. 应用程序或客户端向授权服务器请求授权
  2. 获取到授权后，授权服务器会向应用程序返回访问令牌
  3. 应用程序使用访问令牌来访问受保护资源（如 API）

因为 JWT 签发的 token 中已经包含了用户的身份信息，并且每次请求都会携带，这样服务的就无需保存用户信息，甚至无需去数据库查询，这样就完全符合了 RESTful 的无状态规范。

1.3.4 JWT 存在的问题

说了这么多，JWT 也不是天衣无缝，由客户端维护登录状态带来的一些问题在这里依然存在，举例如下：

  1. 续签问题，这是被很多人诟病的问题之一，传统的 cookie+session 的方案天然的支持续签，但是 jwt 由于服务端不保存用户状态，因此很难完美解决续签问题，如果引入 redis，虽然可以解决问题，但是 jwt 也变得不伦不类了。
  2. 注销问题，由于服务端不再保存用户信息，所以一般可以通过修改 secret 来实现注销，服务端 secret 修改后，已经颁发的未过期的 token 就会认证失败，进而实现注销，不过毕竟没有传统的注销方便。
  3. 密码重置，密码重置后，原本的 token 依然可以访问系统，这时候也需要强制修改 secret。
  4. 基于第 2 点和第 3 点，一般建议不同用户取不同 secret。

当然，为了解决 JWT 存在的问题，也可以将 JWT 结合 Redis 来用，服务端生成的 JWT 字符串存入到 Redis 中并设置过期时间，每次校验的时候，先看 Redis 中是否存在该 JWT 字符串，如果存在就进行后续的校验。但是这种方式有点不伦不类（又成了有状态了）。

2. 实践

我们来看下 gRPC 如何结合 JWT。

2.1 项目创建

首先我先给大家看下我的项目结构：

├── grpc_api
│   ├── pom.xml
│   └── src
├── grpc_client
│   ├── pom.xml
│   └── src
├── grpc_server
│   ├── pom.xml
│   └── src
└── pom.xml

还是跟之前文章中的一样，三个模块，grpc_api 用来存放一些公共的代码。

grpc_server 用来放服务端的代码，我这里服务端主要提供了两个接口：

  1. 登录接口，登录成功之后返回 JWT 字符串。
  2. hello 接口，客户端拿着 JWT 字符串来访问 hello 接口。

grpc_client 则是我的客户端代码。

2.2 grpc_api

我将 protocol buffers 和一些依赖都放在 grpc_api 模块中，因为将来我的 grpc_server 和 grpc_client 都将依赖 grpc_api。

我们来看下这里需要的依赖和插件：

<dependencies>
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt-api</artifactId>
        <version>0.11.5</version>
    </dependency>
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt-impl</artifactId>
        <version>0.11.5</version>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt-jackson</artifactId>
        <version>0.11.5</version>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>io.grpc</groupId>
        <artifactId>grpc-netty-shaded</artifactId>
        <version>1.52.1</version>
    </dependency>
    <dependency>
        <groupId>io.grpc</groupId>
        <artifactId>grpc-protobuf</artifactId>
        <version>1.52.1</version>
    </dependency>
    <dependency>
        <groupId>io.grpc</groupId>
        <artifactId>grpc-stub</artifactId>
        <version>1.52.1</version>
    </dependency>
    <dependency>
        <groupId>org.apache.tomcat</groupId>
        <artifactId>annotations-api</artifactId>
        <version>6.0.53</version>
        <scope>provided</scope>
    </dependency>
</dependencies>
<build>
    <extensions>
        <extension>
            <groupId>kr.motd.maven</groupId>
            <artifactId>os-maven-plugin</artifactId>
            <version>1.6.2</version>
        </extension>
    </extensions>
    <plugins>
        <plugin>
            <groupId>org.xolstice.maven.plugins</groupId>
            <artifactId>protobuf-maven-plugin</artifactId>
            <version>0.6.1</version>
            <configuration>
                <protocArtifact>com.google.protobuf:protoc:3.21.7:exe:$os.detected.classifier</protocArtifact>
                <pluginId>grpc-java</pluginId>
                <pluginArtifact>io.grpc:protoc-gen-grpc-java:1.51.0:exe:$os.detected.classifier</pluginArtifact>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>compile</goal>
                        <goal>compile-custom</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

这里的依赖和插件松哥在本系列的第一篇文章中都已经介绍过了，唯一不同的是，这里引入了 JWT 插件，JWT 我使用了比较流行的 JJWT 这个工具。JJWT 松哥在之前的文章和视频中也都有介绍过，这里就不再啰嗦了。

先来看看我的 Protocol Buffers 文件：

syntax = "proto3";

option java_multiple_files = true;
option java_package = "org.javaboy.grpc.api";
option java_outer_classname = "LoginProto";
import "google/protobuf/wrappers.proto";

package login;

service LoginService 
  rpc login (LoginBody) returns (LoginResponse);


service HelloService
  rpc sayHello(google.protobuf.StringValue) returns (google.protobuf.StringValue);


message LoginBody 
  string username = 1;
  string password = 2;


message LoginResponse 
  string token = 1;

经过前面几篇文章的介绍，这里我就不多说啦，就是定义了两个服务：

  • LoginService：这个登录服务，传入用户名密码，返回登录成功之后的令牌。
  • HelloService：这个就是一个打招呼的服务，传入字符串，返回也是字符串。

定义完成之后，生成对应的代码即可。

接下来再定义一个常量类供 grpc_server 和 grcp_client 使用，如下：

public interface AuthConstant 
    SecretKey JWT_KEY = Keys.hmacShaKeyFor("hello_javaboy_hello_javaboy_hello_javaboy_hello_javaboy_".getBytes());
    Context.Key<String> AUTH_CLIENT_ID = Context.key("clientId");
    String AUTH_HEADER = "Authorization";
    String AUTH_TOKEN_TYPE = "Bearer";

这里的每个常量我都给大家解释下：

  1. JWT_KEY：这个是生成 JWT 字符串以及进行 JWT 字符串校验的密钥。
  2. AUTH_CLIENT_ID：这个是客户端的 ID，即客户端发送来的请求携带了 JWT 字符串，通过 JWT 字符串确认了用户身份，就存在这个变量中。
  3. AUTH_HEADER：这个是携带 JWT 字符串的请求头的 KEY。
  4. AUTH_TOKEN_TYPE：这个是携带 JWT 字符串的请求头的参数前缀，通过这个可以确认参数的类型，常见取值有 Bearer 和 Basic。

如此，我们的 gRPC_api 就定义好了。

2.3 grpc_server

接下来我们来定义 gRPC_server。

首先来定义登录服务：

public class LoginServiceImpl extends LoginServiceGrpc.LoginServiceImplBase 
    @Override
    public void login(LoginBody request, StreamObserver<LoginResponse> responseObserver) 
        String username = request.getUsername();
        String password = request.getPassword();
        if ("javaboy".equals(username) && "123".equals(password)) 
            System.out.println("login success");
            //登录成功
            String jwtToken = Jwts.builder().setSubject(username).signWith(AuthConstant.JWT_KEY).compact();
            responseObserver.onNext(LoginResponse.newBuilder().setToken(jwtToken).build());
            responseObserver.onCompleted();
        else
            System.out.println("login error");
            //登录失败
            responseObserver.onNext(LoginResponse.newBuilder().setToken("login error").build());
            responseObserver.onCompleted();

省事起见，我这里没有连接数据库，用户名和密码固定为 javaboy 和 123。

登录成功之后，就生成一个 JWT 字符串返回。

登录失败，就返回一个 login error 字符串。

再来看我们的 HelloService 服务，如下：

public class HelloServiceImpl extends HelloServiceGrpc.HelloServiceImplBase 
    @Override
    public void sayHello(StringValue request, StreamObserver<StringValue> responseObserver) 
        String clientId = AuthConstant.AUTH_CLIENT_ID.get();
        responseObserver.onNext(StringValue.newBuilder().setValue(clientId + " say hello:" + request.getValue()).build());
        responseObserver.onCompleted();

这个服务就更简单了，不啰嗦。唯一值得说的是 AuthConstant.AUTH_CLIENT_ID.get(); 表示获取当前访问用户的 ID，这个用户 ID 是在拦截器中存入进来的。

最后，我们来看服务端比较重要的拦截器，我们要在拦截器中从请求头中获取到 JWT 令牌并解析，如下：

public class AuthInterceptor implements ServerInterceptor 
    private JwtParser parser = Jwts.parser().setSigningKey(AuthConstant.JWT_KEY);

    @Override
    public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> serverCall, Metadata metadata, ServerCallHandler<ReqT, RespT> serverCallHandler) 
        String authorization = metadata.get(Metadata.Key.of(AuthConstant.AUTH_HEADER, Metadata.ASCII_STRING_MARSHALLER));
        Status status = Status.OK;
        if (authorization == null) 
            status = Status.UNAUTHENTICATED.withDescription("miss authentication token");
         else if (!authorization.startsWith(AuthConstant.AUTH_TOKEN_TYPE)) 
            status = Status.UNAUTHENTICATED.withDescription("unknown token type");
         else 
            Jws<Claims> claims = null;
            String token = authorization.substring(AuthConstant.AUTH_TOKEN_TYPE.length()).trim();
            try 
                claims = parser.parseClaimsJws(token);
             catch (JwtException e) 
                status = Status.UNAUTHENTICATED.withDescription(e.getMessage()).withCause(e);
            
            if (claims != null) 
                Context ctx = Context.current()
                        .withValue(AuthConstant.AUTH_CLIENT_ID, claims.getBody().getSubject());
                return Contexts.interceptCall(ctx, serverCall, metadata, serverCallHandler);
            
        
        serverCall.close(status, new Metadata());
        return new ServerCall.Listener<ReqT>() 
        ;

这段代码逻辑应该好理解：

  1. 首先从 Metadata 中提取出当前请求所携带的 JWT 字符串（相当于从请求头中提取出来）。
  2. 如果第一步提取到的值为 null 或者这个值不是以指定字符 Bearer 开始的，说明这个令牌是一个非法令牌，设置对应的响应 status 即可。
  3. 如果令牌都没有问题的话，接下来就进行令牌的校验，校验失败，则设置相应的 status 即可。
  4. 校验成功的话，我们就会获取到一个 Jws 对象，从这个对象中我们可以提取出来用户名，并存入到 Context 中，将来我们在 HelloServiceImpl 中就可以获取到这里的用户名了。
  5. 最后，登录成功的话，Contexts.interceptCall 方法构建监听器并返回；登录失败，则构建一个空的监听器返回。

最后，我们再来看看启动服务端：

public class LoginServer 
    Server server;

    public static void main(String[] args) throws IOException, InterruptedException 
        LoginServer server = new LoginServer();
        server.start();
        server.blockUntilShutdown();
    

    public void start() throws IOException 
        int port = 50051;
        server = ServerBuilder.forPort(port)
                .addService(new LoginServiceImpl())
                .addService(ServerInterceptors.intercept(new HelloServiceImpl(), new AuthInterceptor()))
                .build()
                .start();
        Runtime.getRuntime().addShutdownHook(new Thread(() -> 
            LoginServer.this.stop();
        ));
    

    private void stop() 
        if (server != null) 
            server.shutdown();
        
    

    private void blockUntilShutdown() throws InterruptedException 
        if (server != null) 
            server.awaitTermination();

这个跟之前的相比就多加了一个 Service，添加 HelloServiceImpl 服务的时候，多加了一个拦截器，换言之，登录的时候，请求是不会被这个认证拦截器拦截的。

好啦，这样我们的 grpc_server 就开发完成了。

2.4 grpc_client

接下来我们来看 grpc_client。

先来看登录：

public class LoginClient 
    public static void main(String[] args) throws InterruptedException 
        ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50051)
                .usePlaintext()
                .build();
        LoginServiceGrpc.LoginServiceStub stub = LoginServiceGrpc.newStub(channel);
        login(stub);
    

    private static void login(LoginServiceGrpc.LoginServiceStub stub) throws InterruptedException 
        CountDownLatch countDownLatch = new CountDownLatch(1);
        stub.login(LoginBody.newBuilder().setUsername("javaboy").setPassword("123").build(), ne
以上是关于手把手教大家在 gRPC 中使用 JWT 完成身份校验的主要内容，如果未能解决你的问题，请参考以下文章
 

 手把手教你 .NET Core 3.1 JWT身份认证


 手把手教你学Dapr - 4. 服务调用


 #私藏项目实操分享# 你了解shiro吗？手把手教你集成shiro


 手把手教你学会 基于JWT的单点登录


 手把手教你AspNetCore WebApi：认证与授权


 ASP.NET Core 搭载 Envoy 实现微服务身份认证(JWT)