[QUERY] AccessToken refresh - should cache expiry be made configurable?

[kagkarlsson]

Query/Question
An AccessToken for a ManagedIdentityCredential expires 2 minutes prior to the actual expiry of the underlying token. As these jwt-tokens seem to have a lifetime of 6-8 hours, would it not make sense to have the refresh happen a bit sooner? Or make it configurable? (to prevent disruptions if the token-refresh fails for more than 2min due to service disruptions)

Why is this not a Bug or a feature Request?
It may be that the answer is "Refresh of tokens via metadata service instance will never fail for more than 2 minutes"..

[maggiepint]

@jianghaolu or @conniey can one of you help here?

[jianghaolu]

The answer is that the HTTP request containing the token should take < 2 minutes to get to the service. When we inspect a cached access token and make sure there's more than 2 minutes life left for it, it's safe to authenticate a request with this token.

Manged identity credentials don't have refresh tokens. Only user based credentials have refresh tokens. If a refresh token expires - there's nothing we can do thus it's unnecessary to have this 2 minute check. But sharing one token implementation with access tokens is just easier :), and 2 minutes is neglectable compared to refresh tokens' usual 90-day life.

We can surely make this configurable - but I'm curious to know your use case for it.

[kagkarlsson]

My point was, if we start trying to get a new token say 30 minutes prior to the expiry of the previous one, then we would be able to handle a 30-minute service disruption where getting a new token fails (for some reason)

[jianghaolu]

@kagkarlsson This is a great scenario I didn't think of. I plan to get this in our next month's release. You are welcome to contribute too!

[kagkarlsson]

Great! Will the PR be public?