You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
.WithClaim(...) behavior change described in Appendix 1 of the proposal above
Acceptance Tests
The following test cases are meant to be tested sequentially.
CCA
Prepopulate the token cache of a CCA with a token token1.
Test a new CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("mismatchingHash") should not trigger refresh.
Test matching hash CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("hashOfToken1") should trigger refresh and obtain a new token token2.
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.
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.
Create a sf = ManagedIdentityClient(...) for Service Fabric. Prepopulate its token cache with a token token1.
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.
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
The text was updated successfully, but these errors were encountered:
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".
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.
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:
ConfidentialClientApplication.AcquireTokenForClient().WithAccessTokenSha256ToRefresh(string hash)
ManagedIdentityClient.AcquireTokenForClient().WithAccessTokenToRefresh(string token)
.WithClaim(...)
behavior change described in Appendix 1 of the proposal aboveAcceptance Tests
The following test cases are meant to be tested sequentially.
CCA
token1
.CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("mismatchingHash")
should not trigger refresh.CCA.AcquireTokenForClient().WithAccessTokenSha256ToRefresh("hashOfToken1")
should trigger refresh and obtain a new tokentoken2
.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.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.
sf = ManagedIdentityClient(...)
for Service Fabric. Prepopulate its token cache with a tokentoken1
.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.claims
andtoken_sha256_to_refresh
behavior.Alternatives
No response
The text was updated successfully, but these errors were encountered: