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:
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?
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?
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: Validate Access Tokens
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.
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?
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.
Given that a private key can only have ONE public key, here are my thoughts.
If the above assumption is true, .well-known/jwks.json can never change.
And if it does, it’s an absolute emergency, meaning that the private key was compromised.
And if that happens, the application owners should probably take immediate action.
When the public key changes, what happens in practice is, that all your issued JWTs becomes invalid! That is more or less a catastrophe.
So, changing the private and the public key in .well-known/jwks.json is not something Auth0 can just do.
Hence, caching the contents of .well-known/jwks.json makes little sense. If the contents of .well-known/jwks.json changes, you should probably take immediate action. Because waiting for the cache to expire makes you vulnerable for that period.
You might as well hardcode it, or make it available via environment variables.
Say the authentication is down or returns intermittent login failure. So we try to login via /oauth/token end point it fails. A new client can’t login and hit our own API.
For existing clients that have logged in, when they try to access our API, they will pass along the access token. Our API then have to verify the token by downloading the JWK from the .well-known/jwks.json endpoint. Will this URL be affected when the authentication API has issues?