gRPC Interceptors for Auth and Logging

Interceptors are gRPC's equivalent of servlet filters — they wrap every RPC call so you can centralize logging, authentication, and metrics without touching service methods. Implement ServerInterceptor, annotate with @GrpcGlobalServerInterceptor, and the starter applies it to every service automatically.

Logging interceptor:

• Wrap the ServerCall with ForwardingServerCall to capture the method name at entry and the status code at exit; override only the methods you need — typically close() for response logging — and delegate everything else to avoid breaking flow control or cancellation propagation
• This gives structured request-response logs without modifying any service code

Auth interceptor:

• Read the Authorization header from gRPC's Metadata, validate the JWT, and either close the call with Status.UNAUTHENTICATED or attach the principal to a Context.Key using Contexts.interceptCall()
• Return a no-op new ServerCall.Listener<>() {} after calling call.close() to prevent the service method from executing on rejected calls — without this, the service still runs after rejection

The context propagation model — the most important detail:

• Unlike Spring Security's SecurityContextHolder which uses ThreadLocal, gRPC's Context is explicitly propagated through Contexts.interceptCall()
• If you use ThreadLocal for auth state, it works fine for unary calls but silently breaks on streaming RPCs where message handlers run on different threads — Context.Key propagates correctly across all gRPC execution models

I recommend always using Context.Key for anything request-scoped in gRPC, and setting @Order on interceptors so auth runs before logging — rejected calls should still appear in access logs.