How to add CallCredentails to grpc requests

[darkmoon221]

Hi everyone,

I'm facing a challenge with Quarkus gRPC (Vert.x gRPC client) and OIDC token integration.
I need to attach a Bearer Token to every outgoing gRPC call, but the token needs to be fetched via the OidcClient.

The Setup:

• Quarkus version: 3.27.2 (LTS)
• Client: Vert.x gRPC Client
• Auth: quarkus-oidc-client
• Using Mutiny-Stubs

The Problem:

I need to fetch the token per request. However, I'm hitting a wall regarding the execution context:

1. Using withCallCredentials: This hasn't worked as expected in my setup (it seems the CallCredentials are not processed by the Vertx implementation).
2. Using a ClientInterceptor: I tried implementing a custom ClientInterceptor.
   • The OidcClient.getTokens() returns a Uni, which is asynchronous.
   • I cannot perform a blocking call (.await().indefinitely()) inside the interceptor because it runs on the Event Loop, leading to an exception (blocks on the event loop are not allowed).
   • The standard gRPC ClientInterceptor API is synchronous, so I cannot easily "wait" for the Uni to resolve before proceeding with next.newCall().

What I've tried:

• Using the @Blocking annotation on the incoming request-handling method. It works but doesn't feel right and somehow contradicts to the reactive principle
• Do it the reactive way, first fetch the token and do the grpc request when receiving it. Although this works, it leads to significant code duplication. I am looking for a centralized, cross-cutting solution (like an interceptor or a global credential provider) so that the business logic doesn't have to manage token lifecycle for every single call.

oidcClient
  .getTokens().onItem().transformToUni(tokens -> 
    taskClient().withInterceptors(new ClientAuthInterceptor(tokens::getAccessToken)).readPendingTasks2(request)
  );

Question:

• What is the recommended "Quarkus-way" to attach async tokens to each grpc call?
• Any guidance or code snippets would be greatly appreciated!

Thanks in advance,
Tobias

[quarkus-bot[bot]]

/cc @alesj (grpc), @cescoffier (grpc)

[sberyozkin]

Hi @darkmoon221

Do it the reactive way, first fetch the token and do the grpc request when receiving it. Although this works, it leads to significant code duplication.

For GRPC, this is likely the only option for now. Can you clarify please your point about the code duplication ?

I am looking for a centralized, cross-cutting solution (like an interceptor or a global credential provider) so that the business logic doesn't have to manage token lifecycle for every single call.

For REST Client, users can annotate their REST Client interfaces with @OidcClientFilter and Quarkus will deal with the OIDC client itself. Is it something similar to what you are looking for for GRPC clients ?

[RinZ27]

The cleanest centralized solution here is a dedicated reactive wrapper around your gRPC client — essentially a thin factory that prepends the token fetch before every call, without touching business logic.

Approach: Token-aware client wrapper

@ApplicationScoped
public class SecureTaskClient {

    @Inject
    OidcClient oidcClient;

    @GrpcClient("task-service")
    MutinyTaskServiceGrpc.MutinyTaskServiceStub taskStub;

    private Uni<MutinyTaskServiceGrpc.MutinyTaskServiceStub> authenticatedStub() {
        return oidcClient.getTokens()
            .map(tokens -> taskStub.withInterceptors(
                new ClientInterceptor() {
                    @Override
                    public <Q, R> ClientCall<Q, R> interceptCall(
                            MethodDescriptor<Q, R> method, CallOptions options, Channel next) {
                        return new ForwardingClientCall.SimpleForwardingClientCall<>(next.newCall(method, options)) {
                            @Override
                            public void start(Listener<R> listener, Metadata headers) {
                                headers.put(
                                    Metadata.Key.of("authorization", Metadata.ASCII_STRING_MARSHALLER),
                                    "Bearer " + tokens.getAccessToken()
                                );
                                super.start(listener, headers);
                            }
                        };
                    }
                }
            ));
    }

    public Uni<TaskResponse> readPendingTasks(TaskRequest request) {
        return authenticatedStub()
            .flatMap(stub -> stub.readPendingTasks(request));
    }
}

Inject SecureTaskClient in your business beans instead of the raw stub — token fetch is centralized, business code sees none of it.

Why withCallCredentials didn't work

The Vert.x gRPC client does not implement the CallCredentials SPI the same way Netty-based gRPC does. CallCredentials.applyRequestMetadata() relies on the executor model of the Netty transport, which is not present in the Vert.x implementation. The interceptor approach above is the correct path for Vert.x gRPC.

Token caching

If you are hitting a high-traffic endpoint, add token caching to avoid fetching a new token per call:

@ApplicationScoped
public class CachedTokenProvider {

    @Inject OidcClient oidcClient;

    private volatile Tokens cached;

    public Uni<String> getAccessToken() {
        if (cached != null && !cached.isAccessTokenExpired()) {
            return Uni.createFrom().item(cached.getAccessToken());
        }
        return oidcClient.getTokens()
            .invoke(t -> this.cached = t)
            .map(Tokens::getAccessToken);
    }
}

Then use cachedTokenProvider.getAccessToken() instead of oidcClient.getTokens() in the wrapper above.

[sberyozkin]

@RinZ27 Injecting Tokens only should also work

[RinZ27]

@sberyozkin Absolutely, injecting Tokens directly is definitely cleaner if we just need to propagate an existing token from the active request context. My wrapper example leaned towards OidcClient primarily for background tasks or service-to-service calls where we must actively fetch and refresh client credentials reactively. Either way works great depending on the exact architecture!