search

solid / authentication-panel

GitHub repository for the Solid Authentication Panel
MIT License
11 stars 15 forks source link

Caching IdP public keys #58

Closed jaxoncreed closed 3 years ago

jaxoncreed commented 4 years ago

I might be wrong about this, but wouldn't recommending the caching of public keys as stated here:

It is RECOMMENDED that the RS keep a list of trusted IdPs, to facilitate the expedient lookup of JWKS through local trust stores or cached public keys.

Be an anti-pattern as it would be recommended that IdPs rotate their keys frequently?

elf-pavlik commented 4 years ago

I think RS could track exp claim on access tokens signed with given key and extend caching that key based on that exp date. IdP should not remove key as long as valid tokens exist signed by that key so caching it based on exp claim in tokens signed by that key seems reasonable.

acoburn commented 4 years ago

Caching should not be a problem. In fact, it should be encouraged.

That said, there are better and worse ways to handle cache invalidation. When an IdP key is rotated, it is important that the new key has a new (unique) identifier in the kid field. This way, if the incoming JWT has a kid value that is not present in the cached JWKS, the resource server can attempt to refresh the cached JWKS data; otherwise, if the kid value is already present in the cache, it can simply use the cached value.

acoburn commented 3 years ago

This issue has been in the can-be-closed? state for over a month with no objections.