Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
PratikPatel-Mtech opened this issue Sep 6, 2024 · 3 comments
Assignees

Comments

@PratikPatel-Mtech
Copy link

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.

@RolandGuijt
Copy link

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.

@RolandGuijt
Copy link

@PratikPatel-Mtech Would you like to follow up on this? If so feel free to do so. If not I'll close the issue.

@RolandGuijt
Copy link

Closing the issue due to inactivity, but feel free to add a comment if you want to follow up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants