SecurityContext not propagated to gRPC executor in servlet mode — @PreAuthorize fails

[nixel2007]

Description

In servlet mode (spring-grpc-server-web), @PreAuthorize on @GrpcService methods fails with AuthenticationCredentialsNotFoundException even though the servlet security filter chain successfully authenticates the request.

Root cause

GrpcServletSecurityConfigurerConfiguration creates two beans:

1. SecurityContextServerInterceptor (captures SecurityContext from SecurityContextHolder)
2. GrpcServerExecutorProvider (wraps an executor in DelegatingSecurityContextExecutor)

However, GrpcServerFactoryAutoConfiguration.GrpcServletConfiguration#grpcServlet does not inject GrpcServerExecutorProvider. The gRPC servlet uses its own default executor where SecurityContextHolder is empty.

As a result:

• Servlet thread (nio-8080-exec-N) authenticates via filter chain, SecurityContextHolder is populated
• SecurityContextServerInterceptor.interceptCall() runs on the gRPC executor thread (not the servlet thread), capturing an empty SecurityContext
• SecurityContextHandlerListener.onHalfClose() restores the empty context
• @PreAuthorize("isAuthenticated()") fails with AuthenticationCredentialsNotFoundException

Steps to reproduce

Minimal reproducer: https://github.com/nixel2007/spring-grpc-security-bug-repro

git clone https://github.com/nixel2007/spring-grpc-security-bug-repro
cd spring-grpc-security-bug-repro
mvn clean compile
mvn spring-boot:run

In another terminal:

docker run --network="host" fullstorydev/grpcurl -plaintext \
  -H 'Authorization: Basic dXNlcjpwYXNzd29yZA==' \
  -d '{"name": "World"}' localhost:8080 com.example.grpcbug.Greeter/SayHello

Result: ERROR — in server logs: AuthenticationCredentialsNotFoundException: An Authentication object was not found in the SecurityContext

Workaround

Setting a DelegatingSecurityContextExecutor on the ServletServerBuilder via ServerBuilderCustomizer fixes the issue:

@Bean
ServerBuilderCustomizer<ServletServerBuilder> fix() {
    return builder -> builder.executor(
            new DelegatingSecurityContextExecutor(Executors.newCachedThreadPool()));
}

The reproducer includes this workaround, toggled via Spring profile fix:

mvn spring-boot:run -Dspring-boot.run.profiles=fix
# Same grpcurl call now succeeds

Suggested fix

GrpcServletConfiguration should use the GrpcServerExecutorProvider bean (if present) when creating the gRPC servlet, similar to how native server configurations handle the executor.

Additionally, it would be beneficial for the default GrpcServerExecutorProvider to attempt injecting an existing TaskExecutor bean (e.g. applicationTaskExecutor) and wrapping it, rather than creating a standalone DelegatingSecurityContextExecutor(Executors.newCachedThreadPool()). This way,
applications that already configure context propagation on their TaskExecutor (e.g. for tracing, MDC, SecurityContext) would get it working out of the box for gRPC as well.

Environment

• spring-grpc 1.0.2
• Spring Boot 4.0.3
• gRPC 1.77.1
• Java 25

Related

• Anonymous can access gRPC method protected by PreAuthorize annotation #245 — similar SecurityContext issue but for native gRPC server mode (fixed in 0.11.0)

[LivingLikeKrillin]

Hi, I'd like to take a look at this issue.

The root cause analysis and suggested fix look clear to me — GrpcServletConfiguration#grpcServlet
should inject the GrpcServerExecutorProvider bean (when present) so that the
DelegatingSecurityContextExecutor is actually applied to the servlet's executor.

I'll verify with the reproducer and submit a PR if no one else is already working on it.
Any guidance or concerns before I start?

[LivingLikeKrillin]

Hi, I investigated this issue and found that the relevant autoconfigure code (GrpcServerExecutorProvider, ServletGrpcServerConfiguration, GrpcServerSecurityAutoConfiguration) has been moved to spring-projects/spring-boot (module spring-boot-grpc-server) as of commit 81b8b54.

Specifically, ServletGrpcServerConfiguration in Spring Boot does not inject GrpcServerExecutorProvider when creating the gRPC servlet, while GrpcServerBuilderCustomizers already handles it for native server configurations.

This fix likely needs to be applied in the spring-projects/spring-boot repository rather than here. Should this issue be transferred or a new issue created on the Spring Boot side?

[LivingLikeKrillin]

Hi, I investigated this issue and found the root cause.

Root cause: Auto-configuration ordering

In spring-grpc 1.0.2, GrpcServerAutoConfiguration and GrpcSecurityAutoConfiguration have no explicit ordering relationship:

• GrpcServerAutoConfiguration: @AutoConfiguration(after = GrpcServerFactoryAutoConfiguration.class)
• GrpcSecurityAutoConfiguration: @AutoConfiguration(afterName = "...SecurityAutoConfiguration")

GrpcServerAutoConfiguration.executorServerConfigurer is gated by @ConditionalOnBean(GrpcServerExecutorProvider.class). When GrpcServerAutoConfiguration is processed before GrpcSecurityAutoConfiguration, the GrpcServerExecutorProvider bean does not yet exist, so the condition fails and the executor customizer is never created. The ServerBuilderCustomizers is then assembled without the executor customizer, and the DelegatingSecurityContextExecutor is never applied to the ServletServerBuilder.

Already fixed in Spring Boot main

The autoconfigure code has since been moved to spring-projects/spring-boot (module/spring-boot-grpc-server), and GrpcServerAutoConfiguration was refactored to inject ObjectProvider<GrpcServerExecutorProvider> directly into GrpcServerBuilderCustomizers, which resolves the ordering issue via lazy resolution.

So this bug exists in spring-grpc 1.0.2 but appears to be resolved in the upcoming Spring Boot release that includes the gRPC module.