Users are facing issues with Azure AD (Microsoft Entra ID) single sign-on (SSO) and token persistence. Common symptoms include: – Frequent re-authentication prompts: Users who have already signed in via SSO are asked to enter credentials again after a short period (e.g., every day or two, or even within hours). For example, they sign in to Office 365, but the next day they must sign in again even though they expected to stay signed in. – Session timeout or expiration messages: Applications might show messages like “Your session has expired” and prompt for login again sooner than expected. In Azure AD sign-in logs, you might see errors such as 50089 – Flow token expired, indicating the refresh token or session token is expired[76][77]. – SSO not working across apps/devices: A user logs into one Azure AD-connected app (say a custom SAML app or Azure Portal), but when navigating to another app that should trust the same login, they get a login prompt. On domain-joined Windows devices, Seamless SSO (Integrated Windows Auth) might not be happening, leading to password prompts where none should occur. – Inconsistent “Keep me signed in” behavior: Users check the “Keep me signed in” box, but still get logged out when closing and reopening the browser or after a short time, which defeats the purpose of that feature.
In short, tokens (access, ID, or refresh tokens) seem to be expiring earlier than they should or the SSO token isn’t being accepted, breaking the seamless login experience.
Possible Root Causes:
- Refresh token/session expiration (Max Inactive Time): By default, Azure AD issues refresh tokens with a sliding window of 90 days for persistent sessions, and a 24-hour window for non-persistent sessions[71]. If a refresh token isn’t used within its inactive interval, Azure AD will no longer accept it, requiring the user to sign in again[71]. For instance, if “Keep me signed in” was not selected (non-persistent), after 24 hours of inactivity the session token expires[71]. This can manifest as users needing to re-enter credentials each morning. The “Flow token expired” error (50089) essentially confirms this scenario – authentication failed because the session token is expired[77].
- Conditional Access Session Policies: If your organization has Conditional Access policies, they can override default token behavior. For example, a Sign-in Frequency policy might require re-authentication every X hours. If a policy is set to a short interval (like every 1 day or every 8 hours), users will be prompted that often, regardless of the underlying token lifetime. Similarly, a Conditional Access policy that does not allow persistent browsers sessions will force users to sign in each time they close and open the browser (the “persistent cookie” is not honored).
- Primary Refresh Token (PRT) issues on Windows devices: The PRT is a key token on Azure AD joined or hybrid AD joined devices that enables SSO without prompts. If the PRT expires or is not available, users on those devices will get authentication prompts unexpectedly. A PRT can fail to refresh if the device is offline for too long, if there’s a time sync issue, or if user credentials changed and didn’t update on the device. By design, the PRT refreshes every 4 hours when possible[73] and has a validity of 14 days (extended to 90 days with activity) for Windows 10/11. If those refresh attempts fail (maybe due to network or configuration issues), eventually the PRT expires and the user is prompted to sign in again on that device[73]. This often affects Seamless SSO: users expect their domain credentials to carry over, but when PRT is missing, Azure AD falls back to asking for credentials.
- Misconfigured token lifetime or legacy policies: Azure AD used to allow configurable token lifetimes via PowerShell (preview features) but they have since been deprecated (as of Oct 2021, refresh and session token lifetimes are fixed by Azure AD)[74]. If at some point a custom policy was set (e.g., to shorten access token to 30 minutes or something), it might still exist in the tenant and cause confusion, though in practice it won’t affect refresh tokens now[86]. In any case, having multiple policies that conflict (or an admin not realizing Conditional Access is controlling something) could cause shorter sessions.
- Application-specific session settings: Some applications that use Azure AD for SSO have their own session timeouts. For example, if Azure AD issues a token to an app, but the app’s internal session is set to expire every 2 hours, the user will be prompted to sign in again (even if Azure AD’s token is still good). This is common in older applications or certain SaaS services that have separate session management. Essentially, Azure AD did its part but the app decided to ask for re-auth (sometimes via a SAML token reissue).
- Browser or cookie issues: Modern browser privacy settings can inadvertently break SSO. If third-party cookies are blocked, and your app tries an iframe SSO or a cross-site SSO, the Azure AD session cookie might not be sent. Or if users frequently clear cookies or use private browsing, the session won’t persist. Also, using multiple accounts in the same browser (like two Office 365 accounts) without proper separation can lead Azure AD to prompt more often.
Diagnostic Methods:
Start with Azure AD Sign-in Logs for affected users: – Look at the Sign-in error details around the times they were prompted unexpectedly. The Result field and Result Detail in each log entry can be revealing. For instance, Result Detail: Refresh token expired indicates the refresh token was expired or revoked, so a fresh login was required. Error code 50089 (mentioned in the question) corresponds to “Flow token expired” which aligns with an expired session/refresh token scenario[76][77]. – Check Conditional Access in the sign-in log: Each sign-in entry will list which conditional access policies were applied. See if a policy requiring reauthentication was triggered. For example, it might show “Sign-in frequency: every 1 day (Policy XYZ)” indicating that’s why the user had to sign in again. If you have a policy set to always require MFA or fresh login under certain conditions, those will be noted. – In Azure AD portal’s Reports, there’s a “Usage > Sign-ins” and specifically a “Authentication Methods” report that can show you if users are doing PRT sign-in or prompt, etc. Also, the Diagnose and Solve section for Azure AD might have an SSO troubleshooting guide. – Primary Refresh Token diagnostics (Windows 10/11): If the issue is on domain-joined Windows devices (where they should have SSO via PRT), use the dsregcmd /status command on an affected machine[87]. Under SSO State, verify: – AzureAdPrt = YES (if NO, the PRT is not present, meaning the device doesn’t have a valid Azure AD token to use for SSO)[79]. – Check AzureAdPrtExpiryTime vs current time and AzureAdPrtUpdateTime[79][80]. If the PRT update time is older than 4 hours, it means the device hasn’t refreshed it recently – possibly a problem[81]. The output may also show an “Attempt Status” with an error code for the last PRT refresh attempt[82] (like 0xc000006d which indicates invalid credentials, often due to password change[83]). This information helps pinpoint if the device’s PRT failed due to credential issues or connectivity. – If any errors are present (in the dsregcmd output or Event Viewer under User Device Registration logs), note them. Errors like AADSTS50126 or others in there can be correlated with documentation for cause. – Token lifetime policies: Use AzureAD or MSGraph PowerShell to list any TokenLifetimePolicies in your tenant (though note these no longer apply to refresh tokens as of 2021)[74]. It’s mostly for thoroughness – likely any such policy is not affecting web sign-in now, but it could affect client apps like SharePoint Online if incorrectly configured (with some legacy). – Reproduce and trace: You can attempt to reproduce the issue with a test user. E.g., log in to a test account, observe if you get the “Stay signed in” prompt and what happens if you say yes or no, then wait 24+ hours idle and see if login is required. This helps confirm if default behavior is the issue or if a custom policy is interfering. Tools like Fiddler or browser dev tools can show if Azure AD is setting cookies and if they persist or get cleared. – If possible, check the application’s logs** or SAML token timing. For SAML apps, the Azure AD-issued token has a default 1 hour lifetime (NotOnOrAfter in token conditions)[84]. After that, the app is supposed to silently get a new token via the user’s session cookie. If that isn’t happening, the user might be prompted. So if the problem is with a particular app integration, consider that the app might just be behaving per token lifetime (which is normal) if there’s no session persistence beyond that. Many apps have settings like “trust session cookie for X hours”.
Proven Solutions:
- Enable Persistent SSO (Keep Me Signed In): If users are being forced to sign in frequently because their session is considered inactive and expiring at 24 hours, enabling persistent sessions can help. Ensure that when users sign in, they either see and accept the “Stay signed in?” prompt or you suppress that prompt and force a persistent session via policy. Microsoft recommends using Conditional Access’s Persistent browser session setting (set to “Always persist” for example) to achieve this[71]. This will make Azure AD issue a persistent refresh token cookie that lives up to 90 days of inactivity. Practically, it means closing the browser or being idle over a day won’t immediately sign them out.
- Additionally, review any Sign-in Frequency CA policy. If you find a policy that says e.g. “reauthenticate every day”, consider relaxing it unless it’s truly needed for security. Perhaps extend it to 7 days or turn it off. Microsoft’s default is no explicit sign-in frequency, which means tokens can live their normal lifetime (90-day sliding window)[72]. Adjusting this policy will directly affect how often users see logins. For example, removing or increasing a stringent sign-in frequency policy has resolved issues for many organizations complaining of too-frequent prompts.
- Fix Seamless SSO / PRT issues: If the root cause is that domain-joined devices aren’t honoring SSO (Kerberos or PRT problems), address those:
- Ensure the Azure AD Seamless SSO feature is correctly configured. Check that the Kerberos ticket for AZUREADSSOACC is being issued in your AD (the computer account used by Azure AD SSO). If not, re-run the Enable-AzureADSSO steps. If users changed their AD password recently, sometimes the Kerberos ticket (which SSO uses to get tokens silently) needs the new password – usually they would lock/unlock workstation to refresh it. Encourage that or have them reboot if needed.
- For PRT issues, if dsregcmd shows the PRT is not there (AzureAdPrt : NO), you might need to have the user sign out of Windows and sign back in with an Azure AD account to get a fresh PRT. If it shows an error like invalid_grant, that often means password changed – signing in interactively on that device (entering credentials once) will update the cached credentials and get a new PRT. Also ensure the device’s time is in sync with internet time (time skew can cause token validation fail).
- Check device status in Azure AD (Devices blade) – if it shows “Disabled” or some issue, that would prevent PRT usage. Re-enable or re-register device as appropriate.
- Once fixed, test that on that device the user can access Office 365 or other Azure AD apps without being prompted. In sign-in logs, these would show “Primary Refresh Token” as the authentication method (rather than Password) for new sessions, meaning SSO is happening via PRT.
- Adjust Conditional Access as needed: If you had a policy disallowing persistent session (maybe for security), consider the trade-off. Microsoft now often suggests using sign-in frequency and persistent session controls carefully to balance security and user experience[75]. Perhaps you can scope such policies only to sensitive apps or accounts, not everyone.
- User guidance and browser settings: Make sure users aren’t unintentionally undermining SSO. If someone always uses Incognito mode, they will always have to sign in. Educate that “Stay signed in” requires not using private browsing and not clearing cookies. Also, in modern browsers, if third-party cookies are blocked globally, instruct users to allow cookies for Azure AD’s login domain (login.microsoftonline.com) or use the Edge Enterprise policy to allow “Authentication cookies” across services. Microsoft documentation points out that blocking third-party cookies can break Seamless SSO.
- Check “Keep me signed in” prompt configuration: In Azure AD > Company Branding, you can disable the KMSI prompt. Microsoft found that most users either dismiss it or it can confuse them. If you disable it, Azure AD treats sign-ins as persistent by default if certain conditions are met (provided Conditional Access doesn’t override) – or you handle via CA entirely. The key is ensuring a persistent cookie is set. So either let users opt in via prompt or enforce it via policy.
- MFA refresh vs SSO: Recognize if prompts are due to MFA. If your CA policy says require MFA every day, then users will be prompted (for MFA, maybe not password each time, but a prompt nonetheless). If that’s the case and it’s not strictly needed, consider lengthening the MFA requirement (maybe every 7 days on trusted devices via Conditional Access).
- Application-specific fixes: If one particular app is kicking users out frequently, check that app’s session config. For example, if using SharePoint Online, use SharePoint’s controls for idle session timeout if needed (the default is relatively long). If a custom SAML app, adjust its session timeout to align with Azure AD’s token (or implement a silent renew, such as using the Azure AD Session cookie to get a new token behind the scenes). For instance, some older apps might not use the refresh token grant to silently get a new access token when the old one expires – implementing that (if it’s your custom app) will allow seamless SSO without user input for longer periods.
- Monitor the outcome: After making adjustments, monitor user sign-in logs and get feedback. You should see:
- Fewer “interactive user” sign-ins in logs for those users (since now more are satisfied by existing session tokens or PRT without prompting).
- The absence or significant reduction of error 50089 and similar in sign-in logs[72]. Instead, you’ll see successes where previously failure details were.
- Users reporting that they are no longer being prompted daily; some may go weeks or months without needing to sign in again, depending on policy.
- If using PRT, sign-in logs for apps will start showing “Authentication Method: PRT” which indicates SSO using the device token.
By aligning token lifetimes with your needs (via Conditional Access) and resolving any device-specific SSO issues, you’ll achieve a smoother single sign-on experience. Users will only be prompted when necessary (like after password changes or defined security reauthentication intervals), rather than annoyingly often.Sources: Microsoft Q&A on Flow token expiry., Azure AD documentation on token lifetimes and session management. Microsoft Entra ID PRT troubleshooting guide