基于grpc-spring-boot-starter的认证放行问题咨询

一、在现有gRPC认证体系里直接放行指定接口 #

你已经用GrpcAuthenticationReader和AuthenticationProvider搭好了全局认证，不用额外写太多代码，两种方式就能搞定放行：

1. 自定义认证过滤器
   继承starter自带的DefaultGrpcAuthenticationFilter，重写shouldAuthenticate方法，判断当前请求是不是要放行的Token获取接口：

@Component
public class CustomGrpcAuthFilter extends DefaultGrpcAuthenticationFilter {

    // 替换成你实际的Token服务方法全路径
    private static final String TOKEN_METHOD_PATH = "/com.your.package.TokenService/GetToken";

    public CustomGrpcAuthFilter(AuthenticationManager authManager, GrpcAuthenticationReader authReader) {
        super(authManager, authReader);
    }

    @Override
    protected boolean shouldAuthenticate(ServerCall<?, ?> call, Metadata headers) {
        // 获取当前调用的方法完整路径
        String currentMethod = call.getMethodDescriptor().getFullMethodName();
        // 是Token接口就跳过认证，其他接口正常走认证
        return !TOKEN_METHOD_PATH.equals(currentMethod);
    }
}

2. 配置文件直接放行（更省心）
   grpc-spring-boot-starter支持直接在配置里指定放行的方法，不用写代码。在application.yml中添加：

grpc:
  server:
    security:
      authorization:
        enabled: true
        permit-all:
          # 填你要放行的gRPC方法全路径
          - "/com.your.package.TokenService/GetToken"

这个方式最简洁，优先推荐。

二、ServerInterceptor的正确用法 #

你之前考虑的ServerInterceptor是可行的，只要让它先于认证拦截器执行就行：

@GrpcGlobalInterceptor
@Order(Ordered.HIGHEST_PRECEDENCE) // 确保这个拦截器最先执行
public class SkipTokenAuthInterceptor implements ServerInterceptor {

    private static final String TOKEN_METHOD_PATH = "/com.your.package.TokenService/GetToken";

    @Override
    public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> call, Metadata headers, ServerCallHandler<ReqT, RespT> next) {
        String currentMethod = call.getMethodDescriptor().getFullMethodName();
        if (TOKEN_METHOD_PATH.equals(currentMethod)) {
            // 直接放行，不触发后续的认证拦截器
            return next.startCall(call, headers);
        }
        // 其他请求继续走原有认证流程
        return next.startCall(call, headers);
    }
}

关键是加@Order把优先级设最高，这样它能在认证拦截器之前判断是否放行。

三、REST接口获取Token的合理性 #

这个方案完全没问题，甚至在很多场景下是必须的：

• 如果有非gRPC客户端（比如前端、传统HTTP服务）要调用你的服务，REST接口兼容性更好，它们没法直接发起gRPC请求。
• 但要注意：给REST接口加防护，比如IP白名单、请求频率限制，防止恶意刷Token；同时Token生成逻辑要和gRPC那边统一，别搞两套体系，不然后续维护麻烦。

总结 #

如果你的调用方都是gRPC服务，优先用配置文件放行gRPC接口的方案，保持技术栈统一；如果有非gRPC客户端，REST接口的方案就留着，两者可以共存。

内容的提问来源于stack exchange，提问作者Pp88