Token minimum validity period: Using Microsoft EntraId to connect to Azure Cache for Redis

Parthasarathy Vasudevan 0

Hi There,

I am working on migrating from accessKey based connection to Azure Cache for Redis to Microsoft EntraId. I am using UAMI/SPN to generate the token and I am told that the Token is valid for roughly 24 hours (probably that is an overarching rule from my organisation). The nature of my application is such that we could have thousands of calls to Redis, hence waiting for the Token to expire and then refresh is not an option.

In my case, I am on a fixed schedule (every 23 hours) refresh cycle. However, I am seeing that the new token is not always 24 hours valid. Example one of it 23 hours 25 minutes, other is 23 hours 41 minutes.

My question is, what is the absolute minimum guaranteed duration that the token will be valid for. This is imperative for me, to make sure, I am not ending up in a situation where the token expires before my schedule kicks in.

Note: I don't want to eagerly validate the token on every call as that will add overhead to my calls resulting in degraded performance offering from my application.

Oury Ba-MSFT 19,581 Reputation points Microsoft Employee

2024-09-17T20:37:52.5466667+00:00

@Parthasarathy Vasudevan Thank you for reaching out.

We recommend requesting a fresh token and reauthenticating the connection when approximately 75% of the original token lifetime has passed. This allows for slight variation in lifetimes, plus allows time for retries if the initial token refresh requests don't succeed.

Are you using SE.Redis? If so you could use our extension library GitHub - Azure/Microsoft.Azure.StackExchangeRedis: Azure-specific wrapper for the StackExchange.Redis client library that takes care of it automatically.

Regards,

Oury
Parthasarathy Vasudevan 0 Reputation points

2024-09-18T08:23:55.5633333+00:00

Hi Oury,

Thanks for your response.

So, your recommendation is to tailor the next refresh based on the current token's validity (75% of it). What is the reason for a variation of token validity between refreshes? Whilst my implementation is based on a fixed schedule, your recommendation seems to be a relative one, any particular reasons this won't/can't be a fixed one?

Also, the second part you mentioned, I have not come across yet, sounds scary, 'retries if the initial token refresh request did not succeed' - what is the usecase of this, is this documented/mentioned anywhere please?

just an add-on to yesterday's timelines, today I have got the token which is valid for 23 hours 15 minutes. This feels very odd to schedule against.

I will take a look at the library, thanks for the suggestion, mine is a java application and also, I am already using Azure library for token generation, I would at this point prefer to Java+Spring libraries.

Regards,

Partha
Parthasarathy Vasudevan 0 Reputation points

2024-09-18T10:05:55.1133333+00:00

Thank you so much for your response Oury.

May I know the reason why the refresh token would have variable validity please? and your advice means the refresh cycle should be relative to the new token and can be fixed schedule. Feels the resource utilization on refreshing the token is optimal this way. What is the strong case to keep this variable?

FYI, my yesterday's refresh token has now a validity of 23 hours 15 minutes (new low).

Also, you have mentioned plus allows time for retries if the initial token refresh requests don't succeed, this is something I have not had any mention, nor did I find in any of Azure documentation. What can cause this? is there a possibility at Random the Token refresh will fail (ofcourse, I am not talking about a case where Token service itself is down). Feels nervous to switch, particularly, in our case, we are going to drop accessKey and use EntraId only.

Lastly about the library, thanks for the reference. Mine is a java based application, I would like to keep it as much as possible with in Java + Spring paradigm for now. Ofcourse, id use Azure library ManagedIdentityCredential to generate token. I will keep the reference handy.

Regards,

Partha
Parthasarathy Vasudevan 0 Reputation points

2024-09-18T10:06:10.1666667+00:00

Thank you so much for your response Oury.

May I know the reason why the refresh token would have variable validity please? and your advice means the refresh cycle should be relative to the new token and can be fixed schedule. Feels the resource utilization on refreshing the token is optimal this way. What is the strong case to keep this variable?

FYI, my yesterday's refresh token has now a validity of 23 hours 15 minutes (new low).

Also, you have mentioned plus allows time for retries if the initial token refresh requests don't succeed, this is something I have not had any mention, nor did I find in any of Azure documentation. What can cause this? is there a possibility at Random the Token refresh will fail (ofcourse, I am not talking about a case where Token service itself is down). Feels nervous to switch, particularly, in our case, we are going to drop accessKey and use EntraId only.

Lastly about the library, thanks for the reference. Mine is a java based application, I would like to keep it as much as possible with in Java + Spring paradigm for now. Ofcourse, id use Azure library ManagedIdentityCredential to generate token. I will keep the reference handy.

Regards,

Partha
ShaktiSingh-MSFT 15,521 Reputation points

2024-09-20T09:49:52.6066667+00:00

Hi Parthasarathy Vasudevan •

We are checking on this internally and will get back to you.

Thanks

1 answer

Oury Ba-MSFT 19,581 Reputation points Microsoft Employee

2024-09-20T15:57:47.76+00:00

@Parthasarathy Vasudevan

Usually, token validity is set by the customer's Entra configuration.

We are not sure what is causing the variability instead of just always exactly 24:00:00. Opening a support ticket might be helpful here.

Regardless, if your system looks into the token to check the expiration, and starts renewal some time before it expires, there shouldn't be any problem with this variability.

It is not expected that token renewal will fail, but there could be network glitches or another unforeseen situation that might cause this. Renewing the token in advance, seems like a reasonable precaution to take.

We are moving towards Entra authentication more and more, and new cache creation in Portal is already defaulting to Entra ON and Access Keys OFF. So, we will encourage customers to move to Entra as it is more secure and definitely the authentication method of preference going forward.

Regards,

Oury
Please sign in to rate this answer.
Oury Ba-MSFT 19,581 Reputation points Microsoft Employee

2024-09-23T21:50:34.65+00:00

@Parthasarathy Vasudevan Checking if the above answer was helpful. Please do let us know if you have further questions.

If the solution answers your query, please don't forget to mark as accept answer.

Regards,

Oury

Parthasarathy Vasudevan 0 Reputation points

2024-09-24T10:58:03.6+00:00

Thanks Oury. I will check internally as well. I have tailored my solution to suit your recommendation, ie after about 75% of its validity period.

Like I mentioned in my previous reply (apologies, got mixed up with comment and reply as the portal was slow to show my response), although we attempt and will embed a retry for failure to refresh, it is a concern if several of this retries fail and spills in beyond the validity of the token. Could you please advice on Microsoft SLA on the EntraId generation service please?
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Token minimum validity period: Using Microsoft EntraId to connect to Azure Cache for Redis

1 answer

Your answer