Azure-sdk-for-java: [QUERY] AccessToken refresh - should cache expiry be made configurable?

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

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.

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)

@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!

Great! Will the PR be public?

Sorry for the delay folks. A PR is open here https://github.com/Azure/azure-sdk-for-java/pull/8715. Feel free to comment there.
We are shipping a preview with this fix next week so further feedback can be addressed afterwards.

@kagkarlsson and anyone interested

We improved this in last week's release https://repo1.maven.org/maven2/com/azure/azure-identity/1.1.0-beta.6/. Not only will you be able to configure the token refresh offset, when the refresh is "proactive", meaning the token isn't actually expired yet, it doesn't throw potential errors from the service. The SDK will block further proactive refreshes for 30 seconds to prevent request flooding, until a valid token is acquired, or the currently cached token expires. The complete design doc can be found at https://github.com/Azure/azure-sdk-for-java/pull/11704.

However, the configurability has raised some concerns internally - we are planning to remove the configurability in the next stable release (1.1.0) coming next month. (but keep the non-failing retries before actual expiry) We are planning to hardcode the token refresh offset, possibly at10% of the token validity.

If you would like to share, would a hardcoded percented offset work? If not, what are some reasons to want the configurability? Would you also want to be able to configure the retry timeout (it's hardcoded at 30 seconds right now)? What are other configurations you would like in the token refresh behavior?