AADSTS50058: Session information isn't sufficient for single sign-on

What does AADSTS50058 mean?

Microsoft’s description:

UserInformationNotProvided: Session information isn’t sufficient for single-sign-on. This means that a user isn’t signed in. This is a common error that’s expected when a user is unauthenticated and hasn’t yet signed in. If this error is encountered in an SSO context where the user has previously signed in, this means that the SSO session was either not found or invalid. This error might be returned to the application if prompt=none is specified.

An app asked Microsoft Entra ID to sign the user in without showing anything and there was no usable session. The app is expected to catch this and show a normal sign-in.

The usual trigger is prompt=none. Microsoft’s authorization code flow reference says it “ensures that the user isn’t presented with any interactive prompt. If the request can’t be completed silently by using single-sign on, the Microsoft identity platform returns an interaction_required error.” The OpenID Connect reference lists the causes: “no signed-in user, the hinted user isn’t signed in, or multiple users are signed in but no hint was provided.” Depending on the flow, the app may get 50058 itself or a protocol error such as login_required or interaction_required. Our reading is that these are the same event seen from two sides; the sign-in log records the AADSTS code.

Is it an attack?

No. Microsoft’s description calls it “a common error that’s expected”. Single-page apps and MSAL.js try silent sign-in first (ssoSilent, acquireTokenSilent) and Microsoft tells developers to “handle any login_required or interaction_required errors with an interactive method”. Every user who opens such an app without a session produces one.

Pattern	Likely meaning
50058 for many users across Microsoft 365 and line-of-business apps	Normal silent SSO attempts. Benign noise.
50058 followed within seconds by a success for the same user and app	The app fell back to an interactive sign-in. Working as designed.
A jump in 50058 for one browser type	Third-party cookie restrictions. Microsoft notes that “ssoSilent requests will fail despite an active user session” in some browsers. Our interpretation: that shows up as extra 50058 rows.
50058 for one user, repeating, with no success after	The app keeps retrying silently and never prompts. A bug in the app, not an attack.

There is no documented attack pattern for 50058. A silent request without a session gets nothing, so it gives an attacker nothing. Exclude it from failure-rate dashboards and spray detections, or it inflates them.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 50058 is logged in. Start by checking where it lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50058"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Which apps generate the noise:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50058"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by AppDisplayName, ClientAppUsed
| sort by Rows desc

Users who hit 50058 and never succeed afterwards on the same app the same day, a sign of an app that doesn’t fall back to an interactive prompt:

let silentFails =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "50058"
    | summarize FirstFail = min(TimeGenerated), Fails = count() by UserPrincipalName, AppId, AppDisplayName;
let successes =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "0"
    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;
silentFails
| join kind=leftouter successes on UserPrincipalName, AppId
| where isnull(LastSuccess) or LastSuccess < FirstFail
| project UserPrincipalName, AppDisplayName, Fails, FirstFail
| sort by Fails desc

If the first query shows most 50058 in AADNonInteractiveUserSignInLogs, run the other two against that table, or both with union. Non-interactive rows are aggregated when application, user, IP address, status and resource match, so row counts there are not request counts. ResultType is a string column, so compare it with "50058", not 50058.

How does Conditional Access affect it?

• 50058 happens before Conditional Access. There is no authenticated user yet, so no policy is evaluated.
• The interactive sign-in that follows goes through MFA and your Conditional Access policies as normal.
• Don’t confuse it with sign-in frequency. A refresh token refused by a sign-in frequency policy is logged as 70043, a different code.

How do I fix AADSTS50058?

For the user: sign in when the app asks. If an app shows this error instead of a sign-in page, the app didn’t fall back to an interactive sign-in; report it to whoever runs the app.

For developers: treat 50058, login_required and interaction_required as “show a sign-in”, not as a failure. With MSAL.js, catch the error from the silent call and call loginPopup, loginRedirect, acquireTokenPopup or acquireTokenRedirect. Pass a login_hint with prompt=none when you know which user to expect.

For admins:

1. Nothing is broken. Exclude "50058" from failure counts, password spray rules and alerting thresholds.
2. If the third query returns many users for one app, that app doesn’t fall back to an interactive sign-in. Report it to its developer.