Description

There is an option to pass a JWK URL in the JWT configuration with Hasura. A lot of providers rotate their JWKs, and hence add a Cache-Control or Expires header to indicate when to next fetch the updated JWKs.

Currently Hasura reads Expires header to figure out when to refresh the JWKs. With this PR, it prioritizes Cache-Control header over Expires to refresh the JWKs.

Affected components

• Server
• Tests

Related Issues

#3301

Solution and Design

It checks for the presence of Cache-Control header in the JWK response. If it is present, it tries to parse the time out of it. If absent, it will try to check for Expires header and try to parse a timestamp out of it.
If it is successful in parsing time from any of the above headers, it will refresh the JWKs after that time. If not found, it defaults to 1min to refresh the JWKs.

This behaviour is same as current, except now Cache-Control header is also read and takes priority over Expires header.

Server checklist

Catalog upgrade

Does this PR change Hasura Catalog version?

• No

Metadata

Does this PR add a new Metadata feature?

• No

GraphQL

• No new GraphQL schema is generated

Breaking changes

• No Breaking changes

Steps to test and verify

Run a server that can respond with a JWK and add a Cache-Control header with max-age=5 seconds. Run Hasura, with the jwk_url of this server in HASURA_GRAPHQL_JWT_SECRET. Observe, that Hasura makes request to this JWK server every 5 seconds.

Limitations, known bugs & workarounds