router
router copied to clipboard
apollographql
JWT/JWKS authentication with support for Auth0/Okta
Is your feature request related to a problem? Please describe. Currently there is no built-in plugin to validate JWT's within the router that use JWKS. This means all security and JWT validation must happen on each subgraph. Moving this validation logic to the router can help reduce the load of subgraphs by rejecting invalid requests earlier, before they are allowed into the network.
Describe the solution you'd like Ideally full support for Auth0/Okta via JWT/JWKS and restricted queries/mutations by roles/scopes.
Describe alternatives you've considered Handle all authentication/authorization logic within subgraphs.
Additional context Auth0/Okta are both widely used by developers, adding support to the Apollo Router will provide support for these solutions out-of-the-box.
Problem
Early adopters of the router will often need to replicate existing custom logic from their apollo-gateway instances, and one piece that will be built across a number of teams will be AuthN-related.
Solution
In order to help accelerate users' development (or remove entirely), we should build support for validating JWKS-backed JWTs for those utilizing that standard as well as providing a reference implementation of an example of an asynchronous AuthN plugin similar to the existing jwt-auth example plugin.
Having either an out of the box solution, or one that is easily customized, will help users migrate to the more performant router and avoid duplicative work.
Why JWKS support?
JWKS, or JSON Web Key Sets, is a standard format for validating incoming JWTs without an explicitly defined shared secret. Given the standardization, it is possible to be used with a number of AuthN providers out of the box, including Auth0 and Okta.
Additionally, given the requirements when using JWKS around refetching, it would provide an example of authentication with asynchronous requirements.
Requirements
At the resolution of this issue, there should be a plugin that supports the following:
- JWKS endpoint entry and validation
- JWT validation against the provided JWKS
- Ability to deny requests with invalid/expired JWTs
- Configurable header location and prefixes, defaulting to
Authorizationand prefixBearer - Support optional authorization, delegating to subgraphs for validation as needed
Is someone working on this plugin already? If not, we're most likely going to have to implement this soon for our organization.
In our particular scenario, forwarding incoming Bearer tokens to be validated using JWKS downstream at the subgraph level isn't possible. The original JWT that the router receives must be validated using JWKS, but the router and subgraph are connected using a router-signed JWT with custom claims to send context over into the subgraph.
No one is currently working on it. If you have questions or need help feel free to ask :)
@andrew-kolesnikov - apologies for the delay on this.
I have a rough example here: https://github.com/apollosolutions/jwks-router-plugin
Make sure to note that this isn't meant for production, but does provide an example implementation of JWKS support w/in the router.
Thank you @lleadbet for posting this - it's been a while so we ended up writing our own plugin, but this is surely going to help a lot of folks out there!
Glad to hear you got something built up! Let us know if you have any questions about plugins and such- always happy to help.
Thanks @lleadbet! Our current challenge is porting query cost calculations from nodejs - we're looking for something like https://github.com/slicknode/graphql-query-complexity for the Rust router. That is something that I think could benefit a lot of folks too, so any suggestions would be much appreciated.
@andrew-kolesnikov - do you mind filing a GH issue with more details on what you'd like to see? Might be useful to spin out that conversation outside the context of this specific plugin ask. :)
Does anyone have any feedback on @lleadbet's solution here they'd be interested in sharing? We're curious about making this part of the Router directly, but would appreciate additional feedback to inform the final shape!
@abernix That example is really close to the plugin I ended up deploying for my needs, pretty good starting point in case someone's looking to add this into their router setup too