When a SAML AuthnRequest with the optional parameter is sent to `Entra ID (Azure Active Directory) without the user having an active session the request fails with a Bad Request error. The error is the following:
AADSTS50058: A silent sign-in request was sent but no user is signed in.
The expected behaviour is to return a Response with a <saml2p:Status> containing an error code like urn:oasis:names:tc:SAML:2.0:status:NoPassive.
This issue seems that it was not present in ADFS but it is still present in Entra ID despite numerous reports (e.g. https://learn.microsoft.com/en-us/answers/questions/1041674/configure-redirect-for-failed-silent-saml-login-in). Most of the answers refer to other authentication workflows supported by Entra ID but are simply irrelevant in the case of SAML.
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.