We are currently using IdentityModel.AspNetCore.OAuth2Introspection in many applications, using a wrapped Keycloak as authorization server.
Some of our business cases are very time critical, therefore we want to enable caching of introspection results. However in an effort to improve performance while not sacrificing security, we have the requirement to cache introspection results for varying amounts of time.
In our case, the recommended cache time is generated on the authorization server and returned as an additional custom claim with the introspection result (based mainly on the token type).
I don't see a way in which this could be achieved with the current implementation, as there is no part between the introspection request and the creation of the cache entry, where custom code could be executed.
My current idea to solve this, would be to add a new event that is fired after the introspection request is done. We could then update the Cache Duration based on the response from our authorization server.
If this would be okay, and there is no other (better) solution, I could propose a PR.
We are currently using IdentityModel.AspNetCore.OAuth2Introspection in many applications, using a wrapped Keycloak as authorization server. Some of our business cases are very time critical, therefore we want to enable caching of introspection results. However in an effort to improve performance while not sacrificing security, we have the requirement to cache introspection results for varying amounts of time. In our case, the recommended cache time is generated on the authorization server and returned as an additional custom claim with the introspection result (based mainly on the token type).
I don't see a way in which this could be achieved with the current implementation, as there is no part between the introspection request and the creation of the cache entry, where custom code could be executed.
My current idea to solve this, would be to add a new event that is fired after the introspection request is done. We could then update the Cache Duration based on the response from our authorization server.
If this would be okay, and there is no other (better) solution, I could propose a PR.