Hey folks - hoping there is some good guidance or clarification that someone can give me regarding the JWT Authentication flows built into the router.
I want to use the Routers @authenticated/@requiresScopes directives to attribute my schema. However, I would also like to support automatic token refreshes when a request is using a token that has expired recently. I attempted to do this using a coprocessor, but it looks like the @authenticated directive is validated before the coprocessor is called, so I don’t have an opportunity to properly refresh an expired token that is being used on a valid session.
Do you guys have a solution for this flow? Or is this something I would have to work around.
I realize I can own the entire authentication flow in my coprocessor, however, it’s not clear to me how I would take advantage of the schema directives if I proceeded with that solution.
Some more information… I’ve been thinking about a proxy option in front of the router… it’s effectively the coprocessor, but running in front of the router instead of next to it….
None-the-less, would still love to control this in a coprocessor (ideally only hit when a token is expired), but realize what I want may not exist yet.
This is what my team is currently doing. We are running the router as a sidecar instead of running the coprocessor as a sidecar. All requests go through our proxy first and then get passed to the router. This gives us the most control over requests as they enter and leave the router.
Since the proxy and router are running on the same hardware, the latency is extremely low but still slightly more than if the coprocessor was the sidecar.
According to Claim augmentation via coprocessors - Apollo GraphQL Docs, it looks like you can add claims to the context by tapping into the router request lifecycle hook with a coprocessor. When combined with Working with JWT claims - Apollo GraphQL Docs, it seems like you should be able to do your token refresh during the router request lifecycle hook and replace the on_error value to Continue. I haven’t tested this out though so I don’t know for sure if it is possible.
Yeah - I read through those docs… but they also call out that if you continue, the request is treated as unauthenticated, so while I would be able to refresh the token in the coprocessor, the request itself would end up returning an invalid result as a result of how it’s treated, so I’m afraid that isn’t an option
Continue: The router continues processing the request when an error occurs during JWT validation. Requests with invalid JWTs will be treated as unauthenticated.
