Fixing AADSTS700082: refresh tokens expiring after 12 hours in Azure Entra External ID
At libelo we use Azure Entra External ID (CIAM) (Customer Identity and Access Management) as the identity provider for our React Native mobile app. We use the Native Authentication API for email + password and the browser-delegated flow for Google and Apple federation. All three flows request offline_access to get a refresh token, exactly as the documentation prescribes for a native/public client.
After our first 'friends & family' release, we started seeing users being logged out of the app overnight. Open the app the next morning, get prompted to sign in again, close the app. Not great for the experience.
The cause was a refresh token lifetime that did not match what the docs describe. This post explains the symptom, what we ruled out, and the actual fix - which turns out to be a configuration setting in Conditional Access, not a bug (anymore) in External ID.
If you arrived here because you are seeing AADSTS700082 with "The refresh token has expired due to inactivity" and exactly 12:00:00 of inactivity reported in the error message, you are in the right place.
The symptom
The user signs in, the app receives an access_token and a refresh_token, everything works. The next time the app comes to foreground - typically the next morning - the silent token refresh call fails with this response:
POST https://yourtenant.ciamlogin.com/yourtenant.onmicrosoft.com/oauth2/v2.0/token
→ 400
{
"error": "invalid_grant",
"error_codes": [700082],
"error_description": "AADSTS700082: The refresh token has expired due to inactivity.
The token was issued on 2026-05-03T12:11:26.5799126Z and was inactive for 12:00:00.
Trace ID: ...
Correlation ID: ...
Timestamp: 2026-05-04 05:33:58Z",
"error_uri": "https://yourtenant.ciamlogin.com/error?code=700082"
}
The interesting part is the constant 12:00:00. Every developer hitting this issue reports the same value. The token is killed exactly twelve hours after issue if the app has not refreshed it in the meantime. For a mobile app that the user opens once a day, that means re-authentication every single morning.
This is the same behaviour discussed in the Microsoft Q&A thread that has been open since 2024 and in this StackOverflow question. Where these threads mostly talk about OTP (One Time Password), we reproduced the behaviour across every identity provider configured in our user flow.
What we ruled out first
The refresh token lifetime documentation lists exactly two scenarios where a refresh token is short-lived rather than getting the 90-day sliding window a native public client should get:
-
SPA platform redirect URIs. When the redirect URI is registered under
spa.redirectUris, the token endpoint enforces Single-Page Application rules and returns a 24-hour refresh token with no inactivity reset. - Email OTP sign-up flow. A specific exception that historically produced short-lived tokens.
Our app registration uses a custom URI scheme (libelo://auth/callback) registered under publicClient.redirectUris, not under spa.redirectUris. And the same 12:00:00 cap reproduces on email + password, Google federation, and Apple federation - so this is not the email OTP edge case either.
In other words, by the documentation we should be getting a 90-day refresh token with a sliding inactivity window. We are getting 12 hours hard-capped. Something else was at play.
The actual cause: Sign-in Frequency
After raising this internally with the Microsoft product group, the answer came back: 'This is not a refresh-token bug. It is the default behaviour of the Sign-in Frequency (SIF) capability in External ID.'
Sign-in Frequency controls how often a user is required to reauthenticate, independent of whether the refresh token itself has technically expired. The session lifetime policy can - and by default in External ID does - cut the refresh token's effective inactivity window down to a value much shorter than the 90 days the underlying token would otherwise support.
That is why the error always says exactly 12:00:00: it is not the refresh token's own lifetime, it is the session lifetime policy invalidating it.
The fix is to configure a Conditional Access adaptive session lifetime policy that matches the experience you want on mobile.
The relevant documentation is here:
The fix: configuring Sign-in Frequency
In the Entra admin center of your specific directory, open Security → Protection → Conditional Access → Policies in the External ID tenant.
This opens a screen like this:
Create a new policy with the following:
Users. Assign to the user population this should apply to. For a customer-facing app this is typically All users (or a specific group if you are rolling this out gradually).
Target resources. Select your application registration - the same client ID the mobile app uses to authenticate. Do not apply this to All cloud apps in a CIAM tenant; you want the policy scoped to the customer-facing app, potentially you want other policies for other platform applications.
Conditions. Optionally restrict to Mobile apps and desktop clients if you want to leave web sessions on a different cadence.
Session controls → Sign-in frequency.
- Set the mode to Periodic reauthentication.
- Set the value to something appropriate for your app. We use 90 days to match the underlying refresh token lifetime, which gives users the "always signed in" experience you would expect from any modern mobile app.
- Enable Persistent browser session as well if you are also covering web flows.
Save the policy and give it a few minutes to propagate. From that point on, refresh tokens issued under that policy will respect the new sign-in frequency value rather than the default 12 hours. (so yes, your users will have to do the authentication round trip again)
Validating it works
The access token , nor the refresh token, specify the expiration time of the refresh token. So, to validate, sign in, leave the app closed overnight, open it the next morning, and check that the silent refresh succeeds without prompting. (I tested this with 3 ios simulators, one for a gmail user, one for apple and one for username/password).
If you want a faster feedback loop, you can also temporarily set the SIF value to one hour, sign in, wait an hour, and confirm the refresh now fails at one hour instead of twelve. That proves the policy is being evaluated against your app registration. Then put it back to 90 days (or whatever value you actually want).
You can also tail the Sign-in logs in the Entra admin centre and look at the Conditional Access tab on a sign-in event. The policy you just created should show up as Applied (or Not applied with a reason, which is what you want to know if it is not working yet).
A few things worth knowing
The 12-hour default is not documented anywhere obvious. This is the bit that cost everyone the most time. The refresh token documentation describes the 90-day sliding window and the SPA / OTP exceptions, and stops there. The fact that the default External ID session lifetime caps refresh at 12 hours regardless of what the underlying token allows is buried in the Conditional Access docs, not in the token docs. So if you went looking in the obvious place, you may not have found it.
The same applies to the workforce tenant flavour of Entra, but the defaults there are different and the typical workforce scenario - a desktop with a Windows session keeping the device active - masks the symptom. On mobile, where the app is genuinely idle for hours between sessions, the cap becomes visible immediately.
This is not specific to the Native Authentication API. We reproduced the same behaviour on the standard browser-delegated authorization_code + PKCE flow. The fix is the same in both cases because the policy is evaluated at the token endpoint, not at the authentication endpoint.
Summary
If you are building a mobile app on Azure Entra External ID and your users are being kicked back to the sign-in screen every twelve hours, the solution was not lying in waiting for a fix for the refresh token duration. The refresh token is behaving as the policy says it should. The behaviour you want is one Conditional Access policy away.
I do think the default value here is the wrong one for a CIAM scenario - a customer mobile app is by definition idle for long stretches, and twelve hours is short enough that nearly every user will notice it - but at least there is a configuration path that solves it cleanly without having to move off the platform.
Hope this saves someone frustrations and time loss.