zitadel
Support a TTL for rp.NewRemoteKeySet cache
Preflight Checklist
- [x] I could not find a solution in the existing issues, docs, nor discussions
- [x] I have joined the ZITADEL chat
Describe your problem
An issuer may remove decide to rotate out a key used to sign OIDC ID Tokens. This may be on a regular-basis, or may be performed in response to a security incident.
The implementation of RemoteKeySet usefully performs some caching of the JWKS, however, if an issuer rotates a key, this will not be reflected until the RemoteKeySet receives a kid that it does not recognise. The RemoteKeySet will continue to verify ID tokens signed with a key that the issuer has rotated, potentially, forever.
Describe your ideal solution
A CacheTTL option that could be provided to NewRemoteKeySet that would set a maximum time for which the cached values would be used without performing a fresh fetch from the remote.
e.g
rp.NewRemoteKeySet(client, jwksUrl, rp.CacheTTL(time.Hour))
Version
N/A
Additional Context
No response
I'd be more than happy to submit a patch for this if maintainers believe this would be appropriate.
@livio-a @muhlemmer can you please have a look and let strideynet know if he should go ahead with contribution? Thanks!
forever
Forever is a long time. Tokens have a exp claim, so in any case an "outdated" public key will not be used over time. In our Zitadel product we had expiry of public keys, which led to a number of issues. This is off course the OP and might not affect the RP as much.
I have nothing against adding some kind of TTL that does some house-keeping in the RP. However, be aware that it might not benefit you as much as you imagine.
Tokens have a exp claim, so in any case an "outdated" public key will not be used over time. ... However, be aware that it might not benefit you as much as you imagine.
In the case that the OP has been compromised and the key-pair exfiltrated, the attacker can issue JWTs with any exp they desire. Hence, why it's important to us that the RP checks "every-so-often" that the keypairs advertised by the OP have not been rotated.
I appreciate this is probably a fairly "edge-case" risk but we're fairly security sensitive and need to consider these kinds of attacks.
I've got nothing against it ;). Just making sure you are aware of the issue we already faced with public key expiry. Feel free to send a PR.