Open kingscott opened 1 year ago
+1
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 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 forgrpc-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.
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
@kingscott Hi there! Were you ever able to put together an example of how to use this middleware in a gRPC environment?
@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.
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.
Checklist
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
andauth0/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 anendpoint.Middleware
in our endpoints, but are unable to becauseCheckJWT
returns anhttp.Handler
.Describe the ideal solution
The existing
CheckJWT
handler could be forked in 2: one that can return a go-kitendpoint.Middleware
, and one that returns anhttp.Handler
; wherein the contents ofCheckJWT
could be abstracted and reused for both handlers. I'd imagine thatTokenExtractor
abilities would need to be expanded, wherein the token could be pulled from context, as in our case. Or,CheckJWT
could callMultiTokenExtractor
instead ofAuthHeaderTokenExtractor
. 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 theCheckJWT
method in a middleware in our codebase that can be pull the token from the passed in context object, and validated manually usingValidateToken
, 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!