Stuck in an SSO Sign-In Loop: Why Browsers Loop and How to Fix It

The user enters their password, approves the MFA prompt, and lands right back on the sign-in page. Sometimes there is no error at all. Sometimes the URL grows longer on each pass. They try again, and again, and open a ticket saying SSO is broken.

A sign-in loop means the identity provider issued a token and the application did not accept it, so it sent the user back to sign in. The fix depends on which side dropped the token. Most cases are on the browser, and a few are on the tenant or the app registration.

Rule out the browser in two minutes

Sign-in flows depend on cookies being written by the identity provider and read back by the app. Anything that blocks third-party cookies, clears cookies mid-flow, or rewrites the request can cause a loop. Prove or clear the browser first, because it is the fastest test.

Open a private or InPrivate window and try the same sign-in. Extensions and most cached state are disabled there. If it works, the user's normal profile is the problem, not the identity provider.

Try an InPrivate or Incognito window. If it works, clear cookies and site data for the app domain and for login.microsoftonline.com (or your provider's domain) in the normal profile.
Disable extensions, especially ad blockers, privacy tools and password managers that inject scripts. Test again with them all off.
Check Edge or Chrome settings for third-party cookies. If they are blocked, add exceptions for the app domain and the identity provider, or allow them for work sites via policy.
Check the PC clock. A clock more than a few minutes off causes token validation to fail, and the app treats it as no token at all.

w32tm /query /status
edge://settings/content/cookies
chrome://settings/content/cookies

When Windows SSO itself is broken

On an Entra-joined or hybrid-joined PC, the browser gets a Primary Refresh Token from Windows and uses it to sign in silently. If that token is stale, the user can be pushed through the interactive sign-in repeatedly while the broken silent path keeps interrupting. This looks like a loop and is really a device registration problem.

Run `dsregcmd /status` and look at the Device State and SSO State sections. AzureAdJoined should be YES on a cloud-joined device, and AzureAdPrt should be YES. If AzureAdPrt is NO, the device cannot get a token and every silent sign-in fails.

AzureAdPrt: NO on a joined device usually means the user has not locked and unlocked since a password change. Have them lock the PC, sign in again, and wait a minute.
If that does not fix it, check Settings > Accounts > Access work or school and confirm the device is listed as connected to your organisation.
On a hybrid device, run `dsregcmd /leave` from an elevated prompt, reboot, and let the scheduled task re-register. Do this only after confirming with whoever owns Entra ID.
Check the Web Account Manager: sign-in problems here show up in Event Viewer under Applications and Services Logs > Microsoft > Windows > AAD.

dsregcmd /status
dsregcmd /leave

Check the tenant and the sign-in logs

If every browser and a fresh device loop the same way, go to the tenant. Open entra.microsoft.com, then Monitoring > Sign-in logs, and filter by the user. Each attempt shows a status and a failure reason. A loop that never records a failure is usually a Conditional Access policy that succeeds, then hands the user to an app that rejects the token for a claim it expected and did not get.

Open the sign-in event and look at the Conditional Access tab. A policy requiring a compliant device, a specific location or a session control the app does not support will produce exactly this behaviour. Common causes include a compliance policy that just changed, a user moved into a new group, or a device that dropped out of Intune.

Filter sign-in logs by the user and the last hour. Look for Interrupted or Failure entries.
Open the Conditional Access tab and note any policy marked Failure or Not applied unexpectedly.
Check the device's compliance state in Intune. A non-compliant device gets blocked after the sign-in completes, which the app renders as a loop.
For third-party SAML apps, check that the reply URL and the entity ID in the app registration match what the app sends. A trailing slash mismatch is enough to cause a loop.
Confirm the user is assigned to the enterprise application if assignment is required.

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@yourdomain.com'" -Top 10 | Select-Object CreatedDateTime, AppDisplayName, Status

Application-side causes

Some loops live entirely inside the app. A load balancer without sticky sessions sends the callback to a different node than the one that started the flow, and the second node has no record of the request. A reverse proxy strips the Set-Cookie header or the SameSite attribute. If the app is one you host, check the proxy config for cookie handling and make sure the callback URL uses the same scheme and host as the app's public address, since a browser will not send a Secure cookie back over plain http.

Frequently asked questions

It works in a private window. Is the user just doing something wrong?

No, the browser profile is carrying something stale. Clear cookies for the app and the identity provider, sign out of the browser profile, and test with extensions disabled. It is the profile, not the user.

Why does only one app loop while Outlook and Teams work?

That app's registration or its Conditional Access policy is different. Check the sign-in logs for that app specifically and look at reply URLs and required claims.

Takeaway

Sign-in loops are a token being issued and thrown away. Test in a private window, check cookies and extensions, then confirm the Primary Refresh Token with dsregcmd. If everything loops everywhere, the Entra sign-in logs and the Conditional Access tab will name the policy or the app registration at fault. Fix the cause rather than telling the user to keep trying.