How are you extending Duende.AccessTokenManagement?

[Erwinvandervalk]

As we work on adding new features to AccessTokenManagement, we've encountered some challenges with its current design, particularly regarding extensibility. The existing approach leans towards inheritance rather than composition, which comes with certain drawbacks. For instance, adding a constructor parameter can immediately introduce a breaking change.

For example, one area where this poses a problem is our caching strategy. To customize the cache key, you currently have to inherit from the cache and override the GenerateCacheKey method. In the next version of Duende.AccessTokenManagement (V4), this inheritance-based approach will be deprecated in favor of injecting a cache key generator.

Looking ahead, our plan is to:

• Minimize the public surface area of the library, exposing only the necessary types for system registration.
• Introduce targeted extensibility points for key scenarios (e.g., cache key generation).

This maximizes the flexibility of the library while minimizing the chances for introducing breaking changes.

To make these improvements as effective as possible, we’d love to hear from you—how are you using and extending Duende.AccessTokenManagement? Your feedback will help shape the future of the library.

[jstclair]

We're extending it today in order to encrypt the token before caching, and then decrypting after reading. For our purposes (and maybe others), it would be useful to expose the value serialization/deserialization as well as choice of key. Maybe someone wants to encrypt the value, or use protobuf rather than json.

[Erwinvandervalk]

Thank you for your reply. That makes sense.

For V4, we're introducing support for HybridCache (as a preview feature). Hybrid cache allows you to plug in your own serialization logic for specific types, so that would be a natural place to implement encryption and or different serialization strategies.

For example:
https://learn.microsoft.com/en-us/aspnet/core/performance/caching/hybrid?view=aspnetcore-9.0#serialization

Would this new design support your needs?

[Erwinvandervalk]

Also, the cache key generation logic is abstracted to a separate interface in V4.