AADSTS50058 - User Session Not Found
Azure AADSTS50058 is a session-context error indicating that a silent authentication request (`prompt=none`) was sent, but Microsoft Entra ID could not find a valid SSO session or accessible identity cookies in the browser.
Last reviewed: April 2, 2026|Editorial standard: source-backed technical guidance
What Does User Session Not Found Mean?
AADSTS50058 is a missing-context signal. When an app uses prompt=none, it is making an assumption: "The user is already logged in to Entra ID in this browser, so just give me a token without asking them." If the SSO cookies are missing, expired, or blocked by the browser’s privacy settings (like Safari’s ITP), Entra ID cannot verify the user’s identity silently and returns this error. It is a mandatory signal to the application that user interaction is now required.
Common Causes
- -Missing SSO Cookies: The user has never signed in on this specific browser, or they manually cleared their cookies.
- -Browser Privacy Restrictions: Intelligent Tracking Prevention (ITP) in Safari or the phase-out of third-party cookies in Chrome prevents the identity provider’s cookies from being read in an iframe.
- -Expired SSO Session: The user was logged in, but their Entra ID session (usually 90 days or governed by CA policies) has timed out.
- -Iframe Blocking: The application is attempting a silent refresh inside an iframe, but the browser blocks cross-site cookie access.
- -Silent Auth Attempted Too Early: The application logic triggers a token request before a primary login has ever been completed.
How to Fix User Session Not Found
- 1Implement Interactive Fallback: This is the standard fix. Catch AADSTS50058 in your code and immediately trigger
loginPopup()orloginRedirect(). - 2Verify Cookie Permissions: Ensure your browser is not blocking cookies from
login.microsoftonline.com. - 3Avoid Iframe-based Silent Auth: Modern browsers are moving away from supporting silent auth in iframes. Use refresh tokens via PKCE, which do not rely on hidden iframes for background updates.
- 4Check Prompt Parameter: Ensure you are not hardcoding
prompt=nonein scenarios where the user might not have a session, such as a first-time visit.
Step-by-Step Diagnosis for User Session Not Found
- 1Open Browser DevTools (F12) and check the Application or Storage tab for cookies under the
login.microsoftonline.comdomain. - 2Inspect the failed network request to Entra ID and check if the
prompt=noneparameter is present in the query string. - 3Test in a different browser. If it works in Chrome but fails in Safari, it is likely an ITP issue.
- 4Check the Microsoft Entra sign-in logs for "Failure reason: User session not found" to confirm it is a session issue and not a conditional access block.
The Silent Auth Lifecycle
- -Request: App sends
prompt=none. - -Check: Entra ID looks for a session cookie (
ESTSAUTH). - -Fail: Cookie is missing or blocked, so AADSTS50058 is returned.
- -Resolution: App must switch to
prompt=select_accountorprompt=login.
Browser Cookie Phase-out Impact
- -As browsers block third-party cookies, traditional silent auth that uses a hidden iframe to talk to Entra ID will consistently fail with AADSTS50058. Moving to MSAL.js 2.x+ with the auth code flow plus PKCE is the recommended architectural migration.
Implementation Examples
const silentRequest = { scopes: ["User.Read"], prompt: "none" };
try {
const loginResponse = await msalInstance.acquireTokenSilent(silentRequest);
} catch (error) {
if (error.errorCode === "AADSTS50058" || error.name === "InteractionRequiredAuthError") {
// Session not found - force interactive login
msalInstance.loginRedirect({ scopes: ["User.Read"] });
}
}How to Verify the Fix
- -Confirm that the application successfully prompts the user for login after the silent attempt fails.
- -Verify that after one successful interactive login, subsequent background token refreshes using refresh tokens work without 50058.
- -Check that the user is not caught in a login loop where the app fails to recognize the interaction requirement.
How to Prevent Recurrence
- -Graceful Degradation: Design your auth service to treat 50058 as a normal interaction requirement rather than a system failure.
- -Refresh Token Usage: Use the
offline_accessscope to obtain refresh tokens, which allow background updates without relying on browser SSO cookies. - -Monitor Session Lifetime: Align your application’s session length with your Entra ID tenant’s token lifetime to minimize unexpected expirations.
- -Pro tip: In MSAL.js, always wrap
acquireTokenSilentin a try-catch block. The catch block is specifically designed to handle AADSTS50058 by calling an interactive method.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.