For gRPC, in theory, you can get UNAUTHENTICATED at any time, including after the client has gotten some results.
If you need to retry calls, and you want to do it transparently, you'd need a gRPC interceptor, yes. (The Flight middleware is not powerful enough to do that.) But that should be separable from authentication itself? As a side note, we have far too many auth methods, especially as some are misleadingly named (e.g. the "basic" auth has little to no relation with HTTP Basic Auth). I suppose a lot of it is just historical stuff that should probably be cleaned up, or at least properly documented. -David On Tue, Feb 8, 2022, at 13:15, José Almeida wrote: > Hi guys, We are assuming the Bearer Token Refresh task, which was started > but now it's been paused for a while (link to original POC) > <[link](https://github.com/apache/arrow/pull/8780)>, and we have some > concerns about it, such as: > > 1 During a Flight Call we can get unauthenticated while consuming a stream > or just when an operation is started? We were wondering if the creation of > a wrapper around the StreamObserver is needed. > 2 Would it be better for an Interceptor to make this Authentication? We > were basing ourselves on this comment > <https://github.com/grpc/grpc-java/issues/5856#issuecomment-511077021>
