The AADSTS160021 “application requested a user session which does not exist” error means Azure cannot find a valid sign-in session for your account.
If this message blocks access to the Azure portal, Entra admin center, Teams, or a custom app, the sign-in flow has lost track of your user session. That can happen when you switch accounts in the same browser, when cached tokens expire in an awkward way, or when you sign in with a personal Microsoft account that has no matching tenant access.
This guide walks through what the AADSTS160021 error actually means, where it usually appears, and the practical steps that clear it in real situations. You will also see a few habits that help keep this sign-in problem from returning during busy workdays.
What The AADSTS160021 User Session Error Actually Means
The message “application requested a user session which does not exist” comes from Microsoft Entra ID, the identity service behind Azure Active Directory. The app you use tries to reuse a sign-in session, but the directory no longer has that session on record, so the request fails with an interaction_required error and the AADSTS160021 code.
In practice this means Azure needs you to perform a fresh interactive sign-in. The browser or client thinks you are still signed in, yet the back-end directory treats that session as gone, expired, or invalid for the resource you are asking for.
Common triggers include switching between work and personal accounts in one browser profile, reusing old bookmarks that point to a different tenant context, or signing in to the portal before your account is actually added to that tenant.
From the app point of view this looks like a token reuse failure. The client asks for a new access token, Azure replies that it needs you again, and the sign-in stalls until you interact.
AADSTS160021 Application Requested A User Session Which Does Not Exist Error Scenarios
While the wording looks technical, the aadsts160021 user session error tends to show up in a small set of patterns. Knowing where you see it helps narrow down the right fix.
| Where You See The Error | Typical Symptom | Quick Direction |
|---|---|---|
| Azure portal or Entra admin center in a browser | Portal banner with “interaction_required” and the full error text | Sign out, clear portal cookies, then sign in with the correct tenant account |
| Microsoft Teams desktop or web | Teams loops on sign-in or shows an auth pop-up that never completes | Clear Teams cache, remove stored Windows credentials, then sign in again |
| Custom app using MSAL or OAuth | Silent token acquisition fails with AADSTS160021 in logs | Force interactive login, then check tenant, account type, and scopes |
These scenarios all boil down to one theme: the client thinks a user session exists, but Microsoft Entra ID does not agree. Fixes usually start with clearing local state, picking the right account, and confirming that the account actually has access in the target tenant.
Root Causes Behind The AADSTS160021 Azure Sign-In Error
Several technical details can sit behind an aadsts160021 application requested a user session which does not exist message. You do not need to wade through protocol traces to resolve it, yet understanding the common roots helps you choose the fastest path.
Behind the scenes Entra tracks sessions with identifiers that connect your browser, device, account, and tenant. When any part of that picture changes too much between requests, the directory stops trusting the earlier session and asks the app to start again.
Using A Personal Microsoft Account In The Wrong Place
One frequent pattern appears when someone signs in to the Azure portal with an Outlook.com or Hotmail email. That personal account first lands in the shared Microsoft services tenant, which does not hold your organization’s subscriptions or Entra configuration. When the portal later tries to call Azure management APIs, the directory cannot map that user session to a tenant that allows those actions, so an AADSTS160021 error appears.
Stale Or Conflicting Browser Sessions
Another pattern involves stale cookies and tokens. Browsers that keep you signed in with several Microsoft accounts at once can send a token for one tenant while the portal expects a different one. By the time you return to that tab, the backing session may already be gone on the directory side, while local cookies still sit in the profile.
Account Not Yet Added To The Tenant
In some cases the user has no link to the tenant at all. For instance, you create an Azure account with a personal email, but no Entra tenant exists yet, or your admin has not invited that email as a guest. When the portal or app tries to look up a user session, the directory cannot find a matching principal, and the request fails with AADSTS160021.
Conditional Access Requiring Fresh Interaction
Conditional access rules can insist on extra checks, such as multi-factor prompts or compliant device status. When those checks require a new interaction, any attempt to reuse an old silent session may fail and throw this error. That is why the message includes the interaction_required label so often.
Fixing AADSTS160021 Application Requested A User Session Which Does Not Exist In Azure Portal
When the Azure portal or Entra admin center shows this error, your goal is to drop stale state and sign in with an account that truly belongs to the right tenant. Work through the steps in order and test the portal after each one so you can see what made the difference.
- Confirm The Account Type — Check whether the top-right profile in the portal shows a work or school account from your organization instead of a personal Outlook email.
- Sign Out From All Microsoft Tabs — Close sensitive blades, then sign out from the portal, Entra admin center, and other Microsoft web apps in that browser profile.
- Use An InPrivate Or Incognito Window — Open a fresh private window so you start with no cached cookies, then browse to the portal link again.
- Choose The Tenant Explicitly — When prompted, pick the correct directory from the tenant picker list, or use a direct URL to a tenant blade to anchor the request.
- Create Or Join A Tenant If Needed — If you only have a personal Microsoft account, create a free Entra tenant or ask an admin to add your email as a guest with the right roles.
- Clear Site Data For Azure And Microsoft — In the browser settings, remove cookies and site data for portal.azure.com, entra.microsoft.com, and login.microsoftonline.com, then try the sign-in flow again.
- Try A Different Browser Profile — Use a clean browser profile dedicated to your admin account so other personal tabs do not share cookies or tokens with it.
If you reach the end of these steps and the portal still reports AADSTS160021, capture the correlation ID and timestamp from the message. An administrator can use those values with Azure sign-in logs to see exactly which tenant and account combination produced the failure.
Fixing The AADSTS160021 Error In Microsoft Teams And Other Clients
Microsoft Teams and other client apps reuse the same sign-in tokens that feed the portal. When those tokens no longer match any user session in the directory, the client may loop on login or show a brief browser-style window with the AADSTS160021 code before closing again.
The general pattern for clients is the same: drop cached credentials, clear local app data, then sign in with an account that has a solid link to the tenant you expect.
- Sign Out Inside The App — Open Teams, sign out from the profile menu, then close the client fully so no background process keeps the session alive.
- Clear App Cache — On Windows, exit Teams, then remove the contents of the Teams cache folders under your user AppData path before starting the client again.
- Remove Stored Credentials — Use Credential Manager on Windows or the password manager on your platform to remove stored entries related to Teams, Azure, or Microsoft Office.
- Sign In With The Right Tenant Account — When Teams restarts, resist the urge to pick the first account you see. Choose the work account that actually belongs to the tenant hosting the team or channel you need.
- Check For Conditional Access Prompts — Watch for extra prompts such as multi-factor challenges or device compliance messages and complete them during the fresh sign-in.
On mobile devices the story is similar, just with different menus. Remove the account from the Teams or Outlook app, clear the app storage from system settings, then add the work account back so the device holds a fresh sign-in for that tenant.
If a custom line-of-business app logs this error from MSAL or another client library, confirm that silent token acquisition falls back to an interactive flow when required. The client should be ready to show a browser window or device prompt so the user can create a new session instead of failing outright.
How To Prevent The AADSTS160021 Error From Returning
Once you clear the immediate aadsts160021 application requested a user session which does not exist issue, a few small habits reduce the chance of seeing it again during a busy day of admin work or collaboration tasks.
- Keep Work And Personal Accounts Separate — Use separate browser profiles for work and personal Microsoft identities so their cookies and sessions do not collide.
- Bookmark Tenant-Specific Links — Save direct links to main Azure or Entra blades for each tenant instead of relying on generic portal entry points.
- Avoid Long-Lived Portal Tabs — Close admin tabs when you finish a task instead of leaving them open for days, since the backing sessions may expire while the tab remains.
- Review Tenant Membership Regularly — Confirm that admins and guests still appear in the right tenants and have the roles they actually need, so sign-ins map to valid directory objects.
- Document Conditional Access Requirements — Make sure users know when to expect extra prompts so they complete them instead of closing the window that would refresh their session.
If you manage more than one tenant, it also helps to watch Azure sign-in logs while you test. Matching your own attempts with the trace and correlation identifiers from error panels gives a clear view of which account and rule set produced each failure.
When you understand that this message reflects a mismatch between local sign-in state and the directory’s view of your user session, the fix becomes less mysterious. Clear the stale pieces, pick the tenant and account with care, and let Azure build a clean session instead of relying on a fragment that no longer exists for regular portal use daily.