Token Cache Key Does Not Consider Updated Scopes, Leading to Stale Tokens

[PratikPatel-Mtech]

Which version of Duende.AccessTokenManagement are you using?
Version 2.1.1 - also tried using the latest version 3.0.0.

Which version of .NET are you using?
Version 8.0

Describe the bug
The TokenRequestParameters, such as scopes and resources, are not considered when building a token cache key (Distributed Cache using Redis). The key is only generated based on the TokenClientName. This causes an issue when new scopes are added to the client, as it continues using the old cached token.

To Reproduce

1. Configure the client using AddClient, setting the scope to user:read and the client name to UserClient. The service will invoke the GET: /v1/users API.
2. Run the application and invoke the code that calls the GET: /v1/users API. Verify that the token is cached using the cleitn name UserClient key.
3. Now, add another scope, user:write, to invoke the POST: /v1/users API.
4. Run the application again and invoke the code that calls the POST: /v1/users API. It will return a 403 error because the cached token is still being used, and it doesn’t include the new user:write scope.

Expected behavior

The token cache key should be generated using both the TokenClientName and the scopes from the TokenRequestParameters. When new scopes or resources are added, the token cache key should be updated to reflect these changes, ensuring that the correct token is used for API calls.

Upon reviewing the method responsible for generating the cache key, it appears that the code to include scopes is present, but the required parameter is not passed from the caller. The missing parameter for scopes should be passed to the cache key generation method to avoid using stale tokens.