Entra access token authentication policies such as BearerTokenAuthenticationPolicy should respect refresh_on information

[christothes]

Long lived credentials such as those received from managed identity authentication include additional metadata concerning when a token can/should be refreshed. Our authentication policies should take this information into account when refreshing access tokens.

This involves:

• Modifying relevant authentication policies
• Modifying the AccessToken type to include this optional information
• Modifying Azure.Identity credential implementations to populate the refresh_on information in the AccessToken

[joshfree]

Related

Azure/azure-sdk-for-java#40027

Azure/azure-sdk-for-python#35473

Azure/azure-sdk-for-js#29576

#22837

Azure/azure-sdk-for-cpp#5598

Azure/azure-sdk-for-rust#1657

[chlowell]

Blocked on AzureAD/microsoft-authentication-library-for-go#239

[chlowell]

🤔 on second thought I believe the only change we need from MSAL is to expose any refresh_in value provided by the STS. Everything else should be feasible in azidentity/azcore. And I can imagine a hacky way to get refresh_in without MSAL's help.

[chlowell]

On third thought, this is blocked because MSAL's token cache has a hardcoded expiration time preventing us from acquiring a new token when a cached one has at least 5 minutes left to expiry.

[andyzhangx]

is anyone working on this bug? that's a critical blocking bug preventing us to use track2. Recently we AKS team found that after migrating to track2 sdk, the managed identity token would expire after 24 hours which is not easy to be caught in e2e test, we have to revert to version using sdk track1, pls fix this issue ASAP, otherwise this track2 sdk is unusable for us, thanks!

[andyzhangx]

here is an example fix in forked branch: hashicorp/go-azure-sdk#362

[chlowell]

Can you please explain how the lack of this feature makes track 2 unusable? What breaks when your application gets a token valid for 24 hours? And how does track 1 help? It doesn't observe refresh_on either.

[andyzhangx]

Can you please explain how the lack of this feature makes track 2 unusable? What breaks when your application gets a token valid for 24 hours?

@chlowell pls refer to https://github.com/Azure/karpenter-poc/issues/554, we need to adjust the token refresh logic, compared with track1 sdk, we hit lots of ExpiredAuthenticationToken error on AKS using track2 sdk, finally we resolved this issue by reverting to version using track1 sdk.

[chlowell]

I think I'm getting the gist of this:

• azidentity uses a 5-minute refresh window for tokens i.e., it refreshes cached tokens when their expiration is less than 5 minutes in the future
  • the track 1 auth package (adal) does this as well, so I guess it has an API for overriding this behavior?
• clock skew in your system grows over time
• mistaken judgments of token expiration time therefore become more likely as token lifetime grows

I feel like I'm still missing something here because the example in your linked issue seems to suggest your application can determine whether a token has expired, implying the Azure SDK could as well. But my understanding may not be important because we do intend to implement this feature and it's blocked on AzureAD/microsoft-authentication-library-for-go#239. MSAL for Go caches tokens for azidentity and has a hardcoded, internal 5-minute refresh window.