Allow middleware to be used in a gRPC environment

[kingscott]

Checklist

• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

We're using Auth0 for user authentication and authorization of our product, and we're also using the auth0/go-jwt-middleware/v2 and auth0/go-jwt-middleware/v2/validator packages to facilitate the validation of access token origins and properties.

We're using go-kit for our API services, and thus would like to use jwtmiddleware.CheckJWT as an endpoint.Middleware in our endpoints, but are unable to because CheckJWT returns an http.Handler.

Describe the ideal solution

The existing CheckJWT handler could be forked in 2: one that can return a go-kit endpoint.Middleware, and one that returns an http.Handler; wherein the contents of CheckJWT could be abstracted and reused for both handlers. I'd imagine that TokenExtractor abilities would need to be expanded, wherein the token could be pulled from context, as in our case. Or, CheckJWT could call MultiTokenExtractor instead of AuthHeaderTokenExtractor. I may be missing some details here, but this is what I've been thinking.

Alternatives and current workarounds

Right now, we're avoiding using the jwtmiddleware.CheckJWT HTTP handler, because we're not able to use the handler in our endpoint layer. I have recreated the CheckJWT method in a middleware in our codebase that can be pull the token from the passed in context object, and validated manually using ValidateToken, and verifying the returned errors.

Additional context

I'd be happy to take a stab at a POC or initial PR for this, if a community contribution is encouraged here. I'm sure that'd grant me some points towards my quarterly Auth0 Ambassador goals. 😄 🙌

Either way, happy to chat more!

[darvid7]

+1

[ewanharris]

Thanks for filing this issue, and apologies for our delay in replying.

We'd definitely like to explore supporting gRPC in some manner in this library but I think given the changes that might require we'd look to potentially restructure this package and cut a new major.

For now it might be best to maybe document the existing usage of jwtValidator.ValidateToken you've described similar to the gin example we have in the repo, demonstrating how to create an interceptor for grpc-go that extracts a token and validates it.

[kingscott]

Thanks for filing this issue, and apologies for our delay in replying.

We'd definitely like to explore supporting gRPC in some manner in this library but I think given the changes that might require we'd look to potentially restructure this package and cut a new major.

For now it might be best to maybe document the existing usage of jwtValidator.ValidateToken you've described similar to the gin example we have in the repo, demonstrating how to create an interceptor for grpc-go that extracts a token and validates it.

Thanks for the reply, @ewanharris. Sorry for the delay on my response as well!

That's not a bad idea. I was able to implement this flow at my company, but just results in some duplicate code since we have both http and grpc flows. I'll try to pick this up when I get a moment.

If I were to put up a PR for this documentation, where should this be added? Thanks.

[ewanharris]

We maintain an examples folder in the repo that would be the place to add it. You can check out one of the other folders in there as an example of the structure that should be followed

[mthssan-toast]

@kingscott Hi there! Were you ever able to put together an example of how to use this middleware in a gRPC environment?

[kingscott]

@mthssan-toast Hey! I haven't been able to put the example together, but I'll do my best to get to it in the next few weeks.

[kingscott]

Submitted a PR here: #244. Let me know if there's anything else you'd like to see here @ewanharris. I tried to be as explicit as possible.