Does the OIDC refresh token need any permanent cache?

[Henri Mikkonen]

> On 12 May 2020, at 21.02, Jim Fox <fox at washington.edu> wrote:
> 
> 
>>      Does the refresh token carry within it enough information for the IdP to issue a new id token?  Or is
>>      there a permanent cache needed somewhere?
>> Yes: all the needed information is encoded inside the refresh_token (which is encrypted via data sealer). Depending
>> on your attribute-resolver configuration, also the attribute/claim values might be included [1].
>> There’s no need (actually not even support at the moment) for any server-side cache/storage regarding them.
> 
> The revocation cache is maintained in server-side storage.  So revocation at one host would still allow refresh tokens to be used on other hosts. Correct?

That’s correct, if the configured storage service (idp.oidc.revocationCache.StorageService -property) is not shared between the hosts. By default, it’s the local in-memory storage service.

> If so, is there a way for me to, via a hook or something, to intercept a refresh request and deny it if the subject was in a local "do not refresh" list - a list that I would maintain by other means?

Unfortunately there’s no support for such a hook at the moment. Anyway, what you just described sounds like one option to implement a feature allowing refresh token revocation for admins. Perhaps for end-users too. Currently the (OAuth2) revocation endpoint (which is called by the RPs) is the only option to revoke access or refresh tokens. This way there wouldn’t be need to maintain the state of all the tokens issued by the OP, as this “do not refresh list” could only contain for instance subjects and timestamps, describing something like "the refresh tokens for subject Y before instant X” are revoked.

BR,
Henri.