I am reading through gRCP authentication and based on what I read, it looks like authentication info (token) is attached as metadata to each call (vs channel).

Did I understand it correctly?

The reason why I am so puzzled is that gRPC is touted to be a protocol to minimize amount of traffic. It looks like adding JWT token to each call would be quite an overhead.

CodePudding user response：

There's two authentication approaches:

1. Channel credentials. This generally means mutual TLS, with client certificates
2. Call credentials. This generally means OAuth or JWT, but it is some sort of bearer token that is sent each request. Basic HTTP authentication would fit into this category.

You get to choose the approach you use. TLS client certificates is definitely the "best" way when it is available, but even in a perfect world it can't always be used. In some instances, like impersonation using 3-legged OAuth, your only option is call credentials.

Sending a call credential each request in Metadata is the same approach as taken with HTTP and is the only real option for something like JWT or OAuth. Mostly independent of gRPC, this type of authentication requires the token to be associated with each request. If the same token is being used repeatedly, HPACK in HTTP/2 can avoid re-sending the entire token in each request, but that mainly just reduces bandwidth usage.

Exchange-based HTTP Header authentication systems are not supported, which means no HTTP Digest. Supporting this type of system would noticeably increase latency, for limited practical gain. NTLM/Kerberos is also exchange-based, but has a strange integration model with HTTP and is not compatible with HTTP/2 at all. This is why IIS and .Net don't support it except on HTTP/1.1.