grpcurl调用GRPC服务正常，Java8集成时遇权限拒绝问题求助

以下是针对「grpcurl带JWT调用正常，但Java8调用返回io.grpc.StatusRuntimeException: PERMISSION_DENIED: Unauthorized」的排查要点：

• 验证Token传递格式与完整性
  gRPC服务的JWT认证通常要求在Metadata的Authorization头中以Bearer <token>格式传递。检查Java代码：

  1. 确认头字段名是Authorization（注意大小写，部分服务严格区分）
  2. 确认格式正确，Bearer与Token之间有且仅有一个空格，没有遗漏或多余字符
  3. 打印Java代码中实际使用的Token，与grpcurl中成功的Token逐字符对比，排查是否存在截断、换行、额外空格等问题

  示例正确代码：

  Metadata metadata = new Metadata();
  Metadata.Key<String> AUTH_KEY = Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER);
  metadata.put(AUTH_KEY, "Bearer " + yourValidJwtToken);
  // 将Metadata附加到Stub
  YourServiceGrpc.YourServiceStub stub = YourServiceGrpc.newStub(channel)
      .withMetadata(metadata);
  

• 检查拦截器配置（若使用拦截器传Token）
  如果通过客户端拦截器统一传递Token，确认拦截器已正确绑定到Stub：

  1. 拦截器逻辑是否正确向Metadata中添加了Authorization头
  2. 是否在创建Stub时通过withInterceptors()方法注入了拦截器
  3. 调试拦截器代码，确认start()方法中的Metadata确实被正确修改

• 排查SSL/TLS配置差异
  若gRPC服务启用了HTTPS：

  1. grpcurl可能默认信任系统证书，而Java客户端未配置正确的信任库，导致请求被拦截（部分服务会以PERMISSION_DENIED而非SSL错误返回）
  2. 可临时尝试使用usePlaintext()启动客户端（若服务允许），验证是否为SSL配置问题

• 确认Token有效性与获取逻辑
  虽然grpcurl调用正常，但仍需检查Java代码中获取Token的逻辑：

  1. 是否从正确的接口获取Token，返回的Token与grpcurl使用的是否一致
  2. 解码Token（可通过jwt.io），确认Payload、过期时间等信息与有效Token完全匹配，排查是否存在缓存旧Token、重复生成错误Token的情况

• 对比grpcurl与Java请求的元数据
  检查grpcurl调用时是否携带了额外的请求头（通过-H参数），比如X-Tenant-ID、User-Agent等。若有，Java代码需将这些头一并添加到Metadata中，确保请求元数据与grpcurl完全一致

• 检查gRPC版本兼容性
  对比grpcurl的版本（执行grpcurl --version查看）与Java客户端依赖的gRPC版本：

  1. 若版本差异过大，可能存在Metadata处理、协议兼容等问题
  2. 尝试将Java gRPC相关依赖（如grpc-netty、grpc-protobuf）升级到与grpcurl一致的版本

内容的提问来源于stack exchange，提问作者Eyyüp TAŞKIN