Entra ID AADSTS50058: Silent Sign-In Request Sent With No Session

AADSTS50058 is reported when an application asks Microsoft Entra IDThe KBY LexiconMicrosoft Entra IDA concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change. Read Full Context for a token without showing any sign-in page, and Entra ID cannot find a signed-in user for that request. The message wording commonly reported for it is that a silent sign-in request was sent but no user is signed in. It is not usually a fault in Entra ID. It is the correct answer to a question the application should not have asked in that state: “give me a token for whoever is signed in” when nobody is, or when the browser did not present the evidence that somebody is.

This guide builds the mental model first: what a session is, what a silent request is, and where the evidence can be lost. It then walks through a worked example, a bounded exercise for a non-production tenant, and a failure-mode table. The Microsoft Entra documentation remains the authoritative reference for exact behaviour, limits and supported procedures. Browser behaviour and library defaults change, so treat the version-sensitive points below as claims to confirm against current documentation before you rely on them.

#Learning Objectives

• Define session cookie, silent request, interactive request and trust boundary in the context of Entra ID sign-in.
• Trace the data flow of a silent token request and identify where AADSTS50058 can arise.
• Diagnose whether the cause is an absent session, a blocked cookie or an application that never falls back to interaction.
• Design and test an interactive fallback, with pass, stop and cleanup conditions.
• Explain which permissions and controls matter when transferring the fix to production.

#Prerequisites

• A non-production Entra tenant, or a test app registration in a tenant where you are authorised to experiment. Do not use production data or real user credentials in examples.
• Permission to view, but not necessarily change, the app registration. Confirm which permissions you actually hold before applying any change.
• A modern browser with developer tools, and familiarity with HTTPThe KBY LexiconHTTPHTTP is a stateless application-level protocol for request and response messages. Safe validation requires a bounded target and both protocol and application evidence. Read Full Context redirects, query strings and cookies.
• Awareness of the library and version your application uses. Confirm the product and library version before applying any change, because defaults differ between versions.

#Content

#

The components involved

Four parts take part in every browser-based sign-in. The application wants a token. The browser stores cookies and decides whether to send them. The Entra ID authorisation endpoint receives the request and evaluates it. The user authenticates when needed. A token is the signed result: it is issued only after Entra ID is satisfied that a particular user is present and the policy allows it.

The session is Entra ID’s record that a user authenticated recently in this browser. Entra ID represents it through cookies set on its own sign-in domain. The application never sees those cookies, and they are a separate thing from the application’s own session. The trust boundary sits here: the application can only ask, and the browser only sends Entra ID’s cookies when its own rules permit that request to carry them.

#

Interactive versus silent requests

An interactive request may display a sign-in page, so a user who has no session can supply credentials. A silent request is an authorisation request that tells the endpoint it must not show any user interface. In OpenID ConnectThe KBY LexiconOpenID ConnectOpenID Connect is an identity layer built on OAuth 2.0 that lets a Relying Party verify who a user is via a signed ID Token, discovery metadata and published signing keys. Read Full Context this is expressed with the parameter prompt=none. If the endpoint can resolve the user from the session cookies, it returns a token or code. If it cannot, it must return an error instead of a sign-in page. AADSTS50058 is that error, in the case where no user could be identified.

This design is deliberate. Silent requests commonly run in a hidden frame, where a sudden sign-in page would be invisible and confusing. The error therefore hands control back to the application, which is expected to start an interactive request.

#

Where the evidence can be lost

Reasoning from cause to effect, the session can be missing for several different reasons, and each needs a different correction.

1. No session exists. The user has not signed in on this browser profile, the session expired, or the user signed out elsewhere.
2. The cookies exist but were not sent. A silent request made from a hidden frame is a cross-site request from the browser’s point of view. Browsers that restrict third-party cookies, privacy modes and extensions can withhold the session cookies in that context. Which browsers do this, and by default or not, is version-sensitive.
3. The application does not fall back. Even when the first two conditions are normal, an app that treats the silent failure as fatal leaves the user stuck instead of requesting interaction.

Cases 1 and 2 are environmental; case 3 is a design fault. Most reliable fixes address case 3 first, because the first two will always happen to some users.

#

Operational consequences

If the app does not handle the error, users see a failed or blank page and may retry repeatedly. Do not respond by loosening security controls such as cookie policies, or by suppressing the error in logs. The error carries useful information: it separates “no session” from “session present but access denied”. Other AADSTS codes, such as AADSTS65001 (consent missing) or AADSTS50105 (user not assigned), indicate a session that was found but a permission that was missing, so they need different fixes. A redirect URI problem produces AADSTS50011 instead.

#Examples

#

Worked example: reading a silent request

The input is an authorisation request shaped like this, with placeholders in place of real identifiers:

1GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
2  ?client_id={test-app-client-id}
3  &response_type=code
4  &redirect_uri={registered-redirect-uri}
5  &scope=openid
6  &prompt=none

Case A: the tester has signed in to the test tenant in the same browser profile and the request is made as a top-level navigation. The expected output is a redirect to the redirect URI carrying an authorisation code. Interpretation: a session existed, the cookies were sent, and the request passed policy.

Case B: the same request is issued from a private window where nobody has signed in. The expected output is a redirect to the redirect URI carrying an error, with AADSTS50058 in the error description. Interpretation: this is correct behaviour. The endpoint had no user to resolve, and prompt=none forbade it from asking one. The fix lies in the application’s handling, not in the tenant.

Case C: the tester is signed in, but the request is issued from a hidden frame in a browser that restricts third-party cookies. The result may be the same error even though a session exists. Interpretation: the evidence was lost at the browser boundary. Comparing cases A and C isolates the cookie-sending rule as the variable.

#Exercises

#

Exercise: provoke the error and prove the fallback

Objective. Observe AADSTS50058 deliberately and confirm that an interactive fallback recovers from it.

Setup. Use a test tenant and a test app registration with a registered redirect URI you control, such as a local development address. Use a test account with no administrative roles. Open two browser profiles: one signed out of Entra, one signed in to the test account. Record your browser and library versions. No tenant setting is changed in this exercise.

1. In the signed-out profile, open developer tools, select the network view and preserve the log. Request the authorisation URL from the worked example. Why: it creates a silent request with no session. Evidence: a redirect carrying an error that includes AADSTS50058.
2. Repeat in the signed-in profile as a top-level navigation. Why: this is the control that shows the endpoint works when a session exists. Evidence: a redirect carrying a code, not an error.
3. In your test app, change the error handler so that when a silent request fails with this error, it starts an interactive request (in MSAL.js, an interactive method such as a popup or redirect acquisition). Library method names differ between versions, so check the library documentation. Why: the application must give the user a path to create a session.
4. Repeat step 1 with the updated app. Evidence: the sign-in page appears, the test user signs in, and a token is obtained.

Pass condition. Step 1 shows the error, step 2 does not, and step 4 completes without a dead end or a loop.

Stop conditions. Stop if you are prompted for credentials for an account that is not a designated test account, if the tenant turns out to be production, if repeated sign-in prompts appear (a possible redirect loop), or if you cannot tell which tenant the app belongs to. Do not try to bypass a Conditional Access block that appears; record it and escalate.

Cleanup. Sign out of both profiles, clear the test cookies in those profiles only, and revert the app change if it was made on a shared branch. No tenant configuration needs reversing because none was changed.

#Validation Guidance

Validate with evidence rather than by feeling that sign-in works. Check these in order:

• The failing request, in the network log, shows prompt=none and the error appears on the redirect back to the app. This confirms the silent path is the one failing.
• The same user succeeds in a top-level navigation in the same profile. This separates a missing session from a cookie-sending restriction.
• After the fix, a signed-out user reaches the sign-in page and returns with a token. A user with a session still gets a token without an unnecessary prompt.
• The Entra sign-in logs for the test tenant show the interactive event for the test user. Which log fields appear, and the retention of logs, depend on licensing and current product behaviour; confirm in the documentation.

Absence of the error alone is weak evidence. It may mean the silent path is no longer being exercised.

#

Failure modes

#Common Mistakes

• Treating the error as a tenant outage. The endpoint is answering correctly. Look at the application and browser first.
• Weakening browser or tenant security to make the error vanish. That widens the attack surface and fixes only one browser configuration.
• Never falling back to interaction. A silent attempt can always fail, so a design that cannot recover is incomplete.
• Confusing this with consent or assignment errors. Those need a session to exist first. See the related error guides linked above.
• Testing only in a profile that is already signed in. The fault then never appears.

#

Production bridge

In production, make the change through the normal change process: application code review, a staged rollout, and a stated rollback, which is usually reverting the deployment. App registration changes need the appropriate application-owner role; do not use a highly privileged role for convenience. Where administrative access to Entra is genuinely needed, prefer time-limited elevation, as in Entra ID PIM, and review who holds it, as in access reviews for privileged roles. Escalate to the identity team when the error persists for users with a verified session, when Conditional Access appears in the sign-in logs, or when the pattern affects many users after a browser release. Related secret problems, such as AADSTS7000215, belong to different flows and should not be investigated here.

#Key Takeaways

• AADSTS50058 means a request that could not show a sign-in page found no resolvable user.
• The session lives in Entra ID cookies the browser may or may not send; the application cannot read them.
• Compare a top-level navigation with a hidden-frame request to locate the loss.
• The durable fix is an interactive fallback with a retry limit, not looser security settings.

Before closing the work, confirm that a signed-out test user reaches a sign-in page and returns with a token, that a signed-in user is not prompted needlessly, and that the sign-in logs show the expected events. Keep the previous application build ready as the rollback boundary, since no tenant setting changed. The next safe decision is to repeat the check in a second browser, then promote the change through staging before any production exposure.