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

[Feature Request] .WithAccessTokenSha256ToRefresh(string hash) and .WithAccessTokenToRefresh(string oldToken) #5111

Open
rayluo opened this issue Feb 5, 2025 · 2 comments

Comments

@rayluo
Copy link
Contributor

rayluo commented Feb 5, 2025

MSAL client type

Confidential, Managed identity

Problem statement

Currently, MSAL provides only unconditional token refresh. We need to support precisely specifying an old token to be refreshed. Details described in Precise Token Cache Refresh proposal.

Proposed solution

A Minimal Viable Product (MVP) shall implement:

  • Chapter 5 of the proposal above
    • ConfidentialClientApplication.AcquireTokenForClient().WithAccessTokenSha256ToRefresh(string hash)
    • ManagedIdentityClient.AcquireTokenForClient().WithAccessTokenToRefresh(string token)
  • .WithClaim(...) behavior change described in Appendix 1 of the proposal above

Acceptance Tests

The following test cases are meant to be tested sequentially.

  1. CCA

    1. Prepopulate the token cache of a CCA with a token token1.
    2. Test a new CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("mismatchingHash") should not trigger refresh.
    3. Test matching hash CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("hashOfToken1") should trigger refresh and obtain a new token token2.
    4. CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("hashOfToken1").WithClaims("..."). This is a client using old token1, with proper hash(token1), even with claims challenge, should NOT trigger refresh, because we can serve it with token2 in cache.
  2. Managed Identity v1. All MSIv1 share same api surface, which will NOT be changed this time, but the behavior for Service Fabric shall be changed.

    1. Create a sf = ManagedIdentityClient(...) for Service Fabric. Prepopulate its token cache with a token token1.
    2. Test a new sf.AcquireToken().WithClaims("foo"). Assert the function call will bypass token cache and trigger a new token request with new parameters ...&api-version=2019-07-01-preview&claims=foo&token_sha256_to_refresh=theHash.
      Note that this .WithClaims(...) behavior is DIFFERENT than CCA's case 4, due to the fact that we currently choose to not introduce a .WithAccessTokenToRefresh() into MSI api.
    3. Redo the previous 2 test cases for IMDS, App Service, etc., and assert that their token requests do NOT contain the new claims and token_sha256_to_refresh behavior.
       

Alternatives

No response

@rayluo rayluo added Feature Request needs attention Delete label after triage untriaged Do not delete. Needed for Automation labels Feb 5, 2025
@bgavrilMS bgavrilMS removed scenario:ManagedIdentity untriaged Do not delete. Needed for Automation needs attention Delete label after triage labels Feb 12, 2025
@bgavrilMS
Copy link
Member

I don't think API this would go on ManagedIdentityClient. We don't want to change the contract between app developers and SDK - they can just use "claims".

@rayluo
Copy link
Contributor Author

rayluo commented Feb 14, 2025

I don't think API this would go on ManagedIdentityClient. We don't want to change the contract between app developers and SDK - they can just use "claims".

Correct. The earlier requirements on ManagedIdentityClient. ... .WithAccessTokenToRefresh(string token) has been crossed out from the "proposed solution" above, but test cases for Managed Identity still remain. Please help proofread them.

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