Refresh Access Token expiry after 14 days

[rangan-anand]

Hello,

I have a daemon app in python which runs in AWS lambda this also have subscription enabled on Inbox(whenever a new mail comes in the Mailbox this app will process the data and load onto a table in backend), and it connects to token cache to access the refresh token to access Graph API, all the setup works without any issue, but after 14 days of initial login, the refresh access token expires automatically and it needs user intervention to authenticate via initiate_device_flow.

I am looking for an alternate approach which reduces the User login. please let me know if there is a workaround?

[rayluo]

I found a Q&A here "For how long I can keep using the refresh token?" (which provides even more detailed information than our standard document).

Could it be possible that your app implementation manage your refresh token (RT) but did not persist subsequent new RT? Does your app utilize MSAL's built-in token cache behavior?

[rangan-anand]

Thanks, is it possible that there is some kind of conditional access policy set on tenant level which triggers this expiry every 14 days,

Thanks in advance.

[rayluo]

You asked the same question 15 days ago. At that time, our follow-up conversation went like this.

we have been updating the token cache every 13 days to avoid failure,

Sounds like you ended up using that workaround and then your app works? You were only asking the "14 days expiration" topic here for clarification?

Regarding the implementation, MSAL's acquire_token_silent() would already update the refresh token (RT). However, the default token cache is in-memory, therefore MSAL won't actually persist the new RT. This behavior and its solution is documented in the sample. If you use such a recommended pattern, you shouldn't need to know those "14 days sliding window" details and write your app for that.

yes, we are using a workaround to avoid the failure for now, I am trying to understand the issue on the app setup so that the workaround could be avoided

My understanding is, the fact that your workaround of updating the tokens every 13 days can bypass the 14-day refresh token (RT) valid window, seems to suggest that your app without your workaround somehow did not update the RT. Can you first double check that aspect?

[rangan-anand]

Hi Rayluo,
the acquire_token_silent_with_error wasn't updating the Access token in token cache persisted on file , so added force_refresh=True now its updating the token cache with the latest access token along with refresh token(RT),

would conditional access have any impact on the token expiry after 14 days, or should this work without any hitch now that i have persisted the RT and access token? please let me know your thoughts. Thanks in advance.

[rayluo]

Hi Rayluo,
the acquire_token_silent_with_error wasn't updating the Access token in token cache persisted on file , so added force_refresh=True now its updating the token cache with the latest access token along with refresh token(RT),

In this message we went through the expected behavior of MSAL's token cache. If your observation "the acquire_token_silent_with_error wasn't updating the Access token in token cache persisted on file" was happening at step No.3 i.e. during the first hour of a newly acquired access token (AT), then it is a correct and desirable behavior.

Always adding force_refresh=True defeats the purpose of a token cache. (That flag only exists for historical and backward compatibility reason. In all other normal cases, you shouldn't need to do force_refresh=True.)

would conditional access have any impact on the token expiry after 14 days, or should this work without any hitch now that i have persisted the RT and access token? please let me know your thoughts. Thanks in advance.

The confusing part to me is you said "now that I have persisted ...". Didn't your earlier message indicate that you've long been using FilePersistence already? Such a discrepancy in observation would normally indicate bugs in the app's implementation.

In the same message above, it also referred to a sample. Together with SerializableTokenCache or FilePersistence it would have already persisted RT and AT by default. Would you mind try running that sample hourly to observe it indeed updates the RT and AT for you, so that we would be confident that the sample would not have the 14-day issue in the first place?

[rayluo]

This troubleshooting conversation became inactive. But to recap our understanding:

• AT will expire soon, RT will also eventually expire, but calling MSAL's acquire_token_silent() will give you a fresh-enough AT whenever possible, and it will automatically maintain the fresh AT & RT in the token cache.
• You should not need to force_refresh.