Configure redirect for failed silent SAML login in Azure AD

Question

Configure redirect for failed silent SAML login in Azure AD

Artu Sa 26

When a silent SAML auth request against Azure Active Directory fails, the result is bad requests. The error is "AADSTS50058: A silent sign-in request was sent but no user is signed in".

We were migrating from ADFS to Azure AD. With ADFS, instead of bad request, we received back a SAML response (with response status urn:oasis:names:tc:SAML:2.0:status:NoPassive).

My question is, can we achieve something similar with Azure AD? Even if we cannot have a SAML response, how could we configure a redirect URI when AADSTS50058 error occurs?

Thanks in advance.

0 comments

1 answer

Your answer

Answer 1

Marilee Turscak-MSFT 37,396 Microsoft Employee Moderator

Hi @Artu Sa ,

Yes, you can catch this error by making an acquireToken call, checking for the error code in the callback, and then redirecting the user to log back in again if you catch that error. So you would handle the acquireToken failure and invoke the acquireTokenRedirect. There is an example of this implementation here. There is also an iframe implementation example added here using a message handler to respond to window messages.

Note also that this error can occur if third party cookies have been disabled in your browser, and you can re-enable third party cookies in your browser to prevent this error from occurring in the first place. If you are using Chrome in incognito mode, the default settings it block third-party cookies.

Additional reference: AADSTS50058 error in Javascript.

Let me know if you have further questions.

-

If the information helped you, please Accept the answer. This will help us and other community members as well.

George-0304 0 Reputation points

2026-05-08T10:15:44.86+00:00

Hi @Marilee Turscak-MSFT

This issue seems to persist in Entra ID as of today. I understand that you provide alternatives -likely oriented toward workflows that do not use SAML- but since this error occurs within a SAML v2 workflow, it simply means the implementation does not adhere to the standard. The standard is quite clear on this point:

[Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0] (page: 49/86, line: 2047) IsPassive [Optional] A Boolean value. If "true", the identity provider and the user agent itself MUST NOT visibly take control of the user interface from the requester and interact with the presenter in a noticeable fashion. If a value is not provided, the default is "false".

Note that the capitalization is not mine. It is more than clear that a SAML IdP should not interrupt the request flow for an AuthnRequest containing isPassive="true". The Entra ID/Azure AD implementation only respects this if the user already has an active session within the respective tenant. If no session cookie is found, Entra ID halts the navigation and displays the AADSTS50058 error page.

While this error code is used across other protocols, its behavior in a SAML context appears to be non-compliant. In my experience with other IdPs, none hijack the browser to inform the user of a missing session. Instead, they redirect back to the Service Provider (SP) with a SAML <Response> indicating a failure to authenticate "passively". Although the standard does not mandate a specific <saml2p:Status> or <saml2p:StatusCode> (leading to some variability among implementations), it is clear that the flow must return to the SP.

Share via

Configure redirect for failed silent SAML login in Azure AD

1 answer

Your answer