Hello, is there any plan for Oathkeeper to accept GRPC requests, not through the GRPC Middleware, but natively? If so, could I help contribute to the OSS for this need, if not already being worked on?

How exactly would it work? We added gRPC as a middleware because it was the easiest way, but I think it would be nice to also support it in proxy mode

Forgive me, as I am not exactly an HTTP expert. But if you have an HTTP/2 server listening, it can identify if it's getting an HTTP/1.1 or HTTP/2 request. If it's HTTP/1.1, do the normal HTTP/1.1 proxy. If it's HTTP/2 with the Content-Type header

'application/grpc+proto'

, then you could extract the authentication metadata from the gRPC headers (token for example) and proxy it upstream. Ideally, you would perform this protocol detection at the very beginning of the request handling, then map everything in such a way that the rest of the business logic stays the same. After hitting the auth server or decision point (the authenticator/authorizer in Oathkeeper terms), you would remap HTTP headers to gRPC metadata for the upstream request, and handle the response body appropriately. I think this is similar to what the ext_auth does in Envoy, which I have been using INSTEAD of oathkeeper, and it seems to work okay. What do you think?

Sure, makes sense. It's just that all the grpc libraries are meant for implementing generated servers, at least the last time I checked. Otherwise, a grpc middleware can handle generic paths. I'm sure there is a way, and we'd greatly appreciate any contributions in that direction. My guess is that you can easily use the existing (and tested) middleware, and just find some way to properly do the forwarding. Currently, oathkeeper also does routing, which is something to consider in grpc, as it mostly works differently. But maybe you can just pass on and let some downstream service do the routing.

You can pull grpc metadata WITHOUT knowing the protodef, then just fwd as HTTP2 and the upstream service will still get it as grpc+protobuf, i can implement an example if helpful My assumption is you would just discard routing, I don't see how that would be helpful for grpc, envoy doesnt do this i think (maybe just routing to a different hostname which should be fine with grpc+proto

ok that sounds reasonable, so basically the same data available in the middleware?

I would assume so yes

There is not much capacity on our side to do it right now, but you could contribute this feature. Probably the middleware code is already doing most of the work you need to do.

Hi5 ty, looking