Auth0 Home Blog Docs

Auth0 Failures getting .well-known/jwks.json

jwks

#1

I am seeing occasional failures when our code attempts to get our .well-known/jwks.json. We are using the JsonWebToken code in the examples here: [https://auth0.com/docs/quickstart/backend/ruby/01-authorization](http://in the Auth0 quickstart documentation here)

Very occasionally, and seemingly randomly, instead of getting the .json file as expected, the response contains an HTML response whose human readable text says:

Auth0
Looks like something went wrong!
We track errors automatically, but if the problem persists feel free to a mailto:support@auth0.com contact us. In the meantime, try again.

So I have two questions about this:

  1. Is our use of the json_web_token.rb strategy, which fetches the jwks.json file for each request we want to authenticate) still the preferred way of validating a JWT token?
  2. Should we cache the jwks.json file and only update it every once in a while, or to use it as a fallback if the HTTPs GET fails?

#2

The JWKS keys have no expiry at the moment, as you can see from the response returned by the endpoint. So you can and probably should cache them for improved application performance/user experience and to avoid running into rate limits.

Verifying JWT tokens using RS256 asymmetric signing algorithm is still the preferred method for verifying tokens: https://auth0.com/docs/api-auth/tutorials/verify-access-token#verify-the-signature

As for the specifics of the our Ruby SDK and how it handles the authentication and verification of the tokens, I am not that familiar with Ruby or the library itself. Since it is a Community supported repository I recommend posting your questions/issues to the GitHub issues page.

You can also read more about the differences between RS256 and HS256 signing algorithms here in this StackOverflow post.

You can cache the JWKS keys as they have not expiry at the moment. You can also look for HTTP response headers and based on the values, stop sending requests to get JWKS and instead use them from your cache.

I hope this helps.
Regards.


#3

This is the stackoverflow link Shayan mentions in his reply: https://stackoverflow.com/questions/39239051/rs256-vs-hs256-whats-the-difference


#4

OK, so I am going to cache the jwks.json file, which as you say has no expiration time.

However, is there anything that COULD cause it to be invalidated or updated, like changing global keys or secrets on the Tennant, or something else of that nature?

When would we need to re-fetch it, if ever?


#5

I can confirm that changing the global secret of the tenant will not update the JWKS keys. You are not allowed to change the Client ID as far as I am aware.

Our node-jkws-rsa library has the cache option with default cache timeout period set to 10 hours. I’d suggest also when you implement caching, that you keep the expiry of the cached keys to 10 hours and then refresh them again.


#6

check out this article-https://auth0.com/blog/navigating-rs256-and-jwks/
wilson