Closed PratikPatel-Mtech closed 1 month ago
Thanks for your detailed analysis. Can you tell us a bit more about why you need to request an extra scope? Please give us a bit more insight into your real world scenario so we can determine if the code as it is needs a change.
@PratikPatel-Mtech Would you like to follow up on this? If so feel free to do so. If not I'll close the issue.
Closing the issue due to inactivity, but feel free to add a comment if you want to follow up.
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
user:read
and the client name toUserClient
. The service will invoke theGET: /v1/users API
.GET: /v1/users API
. Verify that the token is cached using the cleitn nameUserClient
key.user:write
, to invoke thePOST: /v1/users API
.POST: /v1/users API
. It will return a 403 error because the cached token is still being used, and it doesn’t include the newuser: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.