No way to manually manage JWKS?

[huttj-lowes]

The RemoteJWKS seems like a convenient feature to add to the library (although it also feels like bloat, brining in network access).

However, it looks like there's no way to manually refetch the keys, nor does it appear that the agent will periodically refetch. Microsoft docs recommends checking for updates every 24 hours:

At any given point in time, Azure AD may sign an id_token using any one of a certain set of public-private key pairs. Azure AD rotates the possible set of keys on a periodic basis, so your app should be written to handle those key changes automatically. A reasonable frequency to check for updates to the public keys used by Azure AD is every 24 hours.

Can we have either (1) a way to create and manage "local" keystores (ideal for scenarios where the keys are shared via some non-http interface), or (2) a way to force a reload of the keystore?

I honestly think that Jose should focus on key management and allow consumers to define how they retrieve and load the keys. Maybe a separate library could handle AIO validation for the streamlined use case. But, at the very least, there should be a way to configure/force a refetch.

[panva]

Can we have either (1) a way to create and manage "local" keystores (ideal for scenarios where the keys are shared via some non-http interface)

The createRemoteJWKSet module results in a GetKeyFunction interface which is accepted at the different decrypt/verify modules already, so you can definitely build your own.

However, it looks like there's no way to manually refetch the keys, nor does it appear that the agent will periodically refetch.

You do not need to manually refetch because it will automatically do so when no existing key matches the selection criteria. Given good JWKS key management hygiene at the producer this is all that's needed.

I honestly think that Jose should focus on key management and allow consumers to define how they retrieve and load the keys.

I think so too, which is why the key argument for verify/decrypt functions can be an async function where you can resolve the key any way you like.

although it also feels like bloat, brining in network access

has no external network related dependencies and brings in immense value, it's as slim as possible, and you can develop your own.

[panva]

Specifically working with Microsoft's Azure you do not need to re-fetch every day and can rely on the built-in miss to refresh logic, a new kid header parameter encountered in a token will result in a refresh.

[huttj-lowes]

Thanks for that info. I'm not intimately familiar with all the logic. I still worry that if a key is rotated out, but no new kid is introduced, my service would still be validating the old tokens.

[big-kahuna-burger]

@huttj-lowes Proper key rotation implies also new kid in a keyset.

[panva]

I'm not intimately familiar with all the logic.

That's okay. I am tho (see https://github.com/panva).

[huttj-lowes]

Thank you guys for being patient and explaining all of this. Really appreciate it.