Thanks - this discussion is helpful. When I mentioned interceptors I was looking specifically at Java, which is likely to be the language chosen. I am however looking at this from a security perspective as an engineer attempting to evaluate the protocol and the implementation in Java.
I may be having trouble asking my question. As I noted in my first post, it's easy in traditional REST services over HTTP/1.1 to see how continued communication between a client and server is authenticated and authorized. With the popular OAuth 2.0 model as an example, the client may initially authenticate to an /auth endpoint with a token, cert, etc in order to get back a short-lived session grant (usually a JWT). Subsequent calls to the server require that grant to be present in an HTTP header in order to access the requested services. In this pattern, the client must always deliberately present a credential issued to them by the server in order to continue to access the necessary services and resources. The server isn't relying on anything else - the TLS connection, TCP connection, etc to identify the client - only the grant.
I'm trying to relate that to how gRPC continues to identify a client after they've authenticated and a channel has been established. Under the covers, is gRPC associating that channel to the TCP connection such that if the TCP connection is closed, the channel is closed? Is it bound instead to the HTTP/2 stream, which binds a client to the server via TCP or TLS? Or, is there something the client continuously presents with each subsequent call that the server uses to identify them? The implication is that the server can continue to identify the client after a channel has been established; I'm trying to understand how.
Ok, I have a simple POC of a bidrectional streaming RPC up in Java. The client instantiates the non-blocking message stub a single time and the request and response StreamObservers are re-used throughout the communication between client/server.
I confirmed in Wireshark that the same HTTP/2 stream is being reused for all communications. This is ideal and is how our organization will likely implement if/when we start using gRPC.
Implemented on the server is an interceptor - similar to what you've linked in above.
I'm noticing that it's only invoked once, when the channel is first established.
Subsequent communication with the server from the client doesn't result in any new hits to the interceptor. If I don't reuse streams it will be invoked every time new streams are established. Is this expected behavior - for interceptors only to fire during the first time a client makes a call over a newly established stream? If so then I come back to my original question that started this thread: how would we consider the established stream and channel secure, how how does the server continue to trust that it's the same client with which it's communicating?
Thanks in advance. If there's a more appropriate place to get ongoing support for questions such as these, please let me know.
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c28cc011-2889-4adb-9f50-093427ac4e2dn%40googlegroups.com.
how would we consider the established stream and channel secure, how how does the server continue to trust that it's the same client with which it's communicating?
This is why web-based applications have session tokens/cookies, web services always authenticate or use tokens like JWTs, etc, where those credentials are protected cryptographically via TLS or other encryption/signing schemes.
The channel (stateful connection in this case - not to be confused with a gRPC channel) alone is only considered adequate if it binds the client to the server, which can be achieved via TLS but only if the server associates the TLS session with the client. Many web servers don't do this.
If you are using TLS, then it provides that guarantee. If you are using insecure channel credentials, then you'd only be trusting your datacenter network.
gRPC does not support this. It interacts poorly with load balancing. In gRPC, if you want to authenticate only once per connection, use mTLS.
I'll note that a bearer token sent each RPC generally isn't a performance concern in gRPC. HTTP/2 can avoid resending the full token value in each request (via compression) and if the server has a cache, then there would be little per-RPC overhead.