What is the advantage of JWK over just the public key (stored as a PEM)?

[bookercodes]

I am new to Auth0 and not terribly knowledgeable about JWT.

Assuming I already have an (RS256) access token returned by Auth0.

On the server, I would now like to verify the token.

To verify the token, I need to use my application’s public key. From what I understand, I can attain this public key a few different ways:

• I could download the public key from Settings Show Advanced Settings DOWNLOAD CERTIFICATE
• I could use a JWK library which, based on data encoded in the access token, knows to fetch the JWK from https://DOMAIN.eu.auth0.com/.well-known/jwks.json via an HTTP request (and, optionally, cache it)

It seems like Auth0 encourages users to use JWK, but what are the practical benefits? I read the Auth0 documentation but unfortunately, I am still unclear.

I am specifically curious why libraries like express-jwks fetch the data from https://DOMAIN.eu.auth0.com/.well-known/jwks.json and, in many cases, temporarily cache it. Is this purely for convenience?

In my case, I am intending to deploy my code as an AWS Lambda function. I am new to this technology as well, but due to the stateless nature of cloud functions, I don’t expect I can cache the JWK easily. In that case, would it make sense to fetch the JWK with each auth request? Surely there must be an upside to justify this; otherwise, I could simply store the public key locally as a PEM?

Thank you for taking the time to read my question.

[nicolas_sabena]

Hi @bookercodes. I can think of three basic advantages of using the JWKS:

• It’s an OIDC standard (including the /.well-known/jwks.json path), which means that many OIDC libraries can assume that the information will be there and do all the work of getting the keys for you.
• In the rare event that keys are rotated (not something that Auth0 does at this moment, but could potentially be added at some point) the application could go and grab the new certificate dynamically. Again, something that some OIDC libraries do for you.
• The OIDC provide might be forced to rotate the keys (e.g. in the case that current keys are somehow compromised, or that new security recommendations call for new certificate types). This would be a very rare event, of course, but the downtime for the application would be far less if it can go and fetch the new key automatically.
• Managing configuration values on deployments is usually a pain, so this is one less problem to worry about.

Having said that (and not sure about AWS’s caching possibilities), getting the JWKS on every request seems totally overkill, and hard-coding the certificate in the Lambda function could be an acceptable compromise.

[bookercodes]

Hi @nikola.vranesic, thank you for your response. This has given me a lot of clarity and I appreciate it!