When does JWK expire? JWKS rotation policy

Question

I am reading about JWKS and found information about the key rotation concept - https://developer.okta.com/docs/concepts/key-rotation/

Let's assume I use JWKS in my application but I don't fetch them periodically, so just hardcoded. The single key JSON object looks like

{
      "kty": "RSA",
      "e": "xxx",
      "use": "sig",
      "kid": "xxx",
      "x5t": "xx",
      "x5c": [
        "xxx"
      ],
      "n": "xxx

}

The JWKS provides you the public key so you can validate JWT. Now questions.

1. Is it possible to get information when JWKS expires? For example, can I generate a .cert file using a JWK and open it to check expiration day?
2. Does the JWKS provider expose information when the key rotation is planned or maybe it is sensitive information?

And please consider the example above, so I have keys in the application and would like to know when I should replace them.

Of course I know that it is bad practice (I should fetched keys directly from JWKS endpoint and feel safe) but this is only an example (if it is a stupid example, please propose a better one just to describe the context).

Answer 1

1. JSON Web Key Set (JWKS aka JWK Set) is a list of JSON Web Keys (JWKs). Since JWK Set is simply a container, it contains no metadata such as an expiration date/time.

2. It does not expose this for at least two reasons:

• RFC 7517 is the specification that governs the behavior of JWKs and JWK Set. It does not mention or require the provider to publish an expiration date/time. Perhaps this is so due to reason #2:
• The provider should be able to remove keys for any reason at any time. Possible reason: key has been compromised. (For a private/public keypair, this would mean the private key has been compromised and the corresponding public key published via JWKS should be removed from circulation). This example is an outlier but it does happen and the provider would have to act immediately to fix it.

Emergencies notwithstanding, providers do rotate keys on a regular basis as a matter of good security hygiene. To handle key rotation (be it planned or emergency), your application should adhere to a simple algorithm. It should periodically fetch the keys from JWKS endpoint, build a local replica of all keys and add/remove keys from this replica based on the last fetch. Only keys found in the local replica should be used by your application to perform a cryptographic operation such as verifying a signature on a JWT.

Each JWK has a kid (key id) parameter and this parameter is used to match a specific key. RFC 7517 recommends using kid to choose among a set of keys within a JWK Set during key rollover. When your application does a fetch of keys from JWKS, you'll be comparing the set of keys coming from JWKs to the set of keys in your local replica. The comparison is based on kid. If a key with some kid is present in JWKS but not present in your local replica, you should add this key to your replica. Vice versa, if a key with some kid is present in your local replica but not present in JWKS, you should remove this key from your local replica.

How frequently should your application fetch the keys from JWKS? This is up to you, it depends on the risk tolerance of your app and/or your organization. Some apps fetch every minute, others do it hourly or daily.

Let's say your app never does this fetch, the key is hardcoded in your app. This will work until the key is removed by the provider. (We're assuming that we're talking about a public key here. A JWK could represent a private key...and that you will not want to embed into your app). Some providers don't rotate keys or do so once in a very long while. If you're dealing with a well-known (to you) provider and they guarantee to you that they won't rotate keys, your risk of embedding a key into your app is low.

In general, embedding a public key into the app is not a good idea. If you're going to be using a JWKS endpoint, implement a simple fetch + update solution as outlined above.