Silent SSO failed. login_required: AADSTS50058: A silent sign-in request was sent but no user is signed in.

[nipothar]

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.26.0

Wrapper Library

Not Applicable

Wrapper Library Version

None

Public or Confidential Client?

Public

Description

We are getting a SilentSSO failed for our application and we are trying to resolve this..

• We have enabled verbose logging but that did not give us any useful information (included all the logs below) so we just recently disabled it and kept the warning and error logs.

Attempted Steps:

There was one warning that was appearing fairly consistently which was:
Warning - No user hint provided. The authorization server may need more information to complete this request.

For this, we are already sending account information into the request based on this recommendation: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/login-user.md#account-apis (please see the code snippet below).

However, the warning is still persists, we made sure that the login hint was being sent through. Not sure if this is related to the issue with SilentSSO.

Couple questions here:

• What is the functionality of the loginHint when it comes to calling the ssoSilent requests?
• Do we need to explicitly set the loginHint if the account is already being sent in the request? If so, what is the reasoning behind this?
• Is there anything else missing that you think we need to have that would help us resolve the SSOSilent error?
• We are already calling acquireTokenRedirect after catching the error, is that the only alternative or is there any way to resolve this bug?

Error Message

Silent SSO failed. login_required: AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoftonline.com).

Msal Logs

• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : @azure/msal-browser@2.26.0 : Verbose - ssoSilent called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - getRedirectUri called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - getClientConfiguration called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - validateAndExtractStateFromHash called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - initializeAuthorizationRequest called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - initializeServerTelemetryManager called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - initializeAuthorizationRequest called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : @azure/msal-browser@2.26.0 : Verbose - PerformanceClient: Measurement found for ssoSilent
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : @azure/msal-browser@2.26.0 : Verbose - PerformanceClient: Emitting performance events
• MSAL module log 1: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Warning - No user hint provided. The authorization server may need more information to complete this request.
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Creating discovered authority with configured authority
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Auth code client created
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - InteractionHandler.handleCodeResponse called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : @azure/msal-browser@2.26.0 : Verbose - ssoSilent called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - acquireTokenByIframe called
• MSAL module log 1: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Warning - No user hint provided. The authorization server may need more information to complete this request.
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - initializeAuthorizationRequest called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - getRedirectUri called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Initializing BaseAuthRequest
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Authentication Scheme wasn't explicitly set in request, defaulting to "Bearer" request
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - initializeServerTelemetryManager called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - getClientConfiguration called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - getDiscoveredAuthority called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Creating discovered authority with configured authority
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Auth code client created
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - initializeAuthorizationRequest called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - validateAndExtractStateFromHash called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - Returning state from hash
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : msal.js.browser@2.26.0 : Verbose - InteractionHandler.handleCodeResponse called
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : @azure/msal-browser@2.26.0 : Verbose - PerformanceClient: Measurement found for ssoSilent
• MSAL module verbose log: [Thu, 25 Aug 2022 17:27:06 GMT] : [ab7dff44-92c6-4eb5-be22-6a4ceb6819fb] : @azure/msal-browser@2.26.0 : Verbose - PerformanceClient: Emitting performance events

MSAL Configuration

configuration = {
            auth: {
                authority: `${Settings.AuthorityBaseUrl}/${Settings.UnknownTenant}`,
                clientId: Settings.ClientId,
                navigateToLoginRequestUrl: true,
                postLogoutRedirectUri: `https://${window.location.host}${Settings.SignOutRedirectPath}`,
                redirectUri: `https://${window.location.host}${Settings.SignInRedirectPath}`,
            },
            cache: {
                cacheLocation: getStorageType(),
                // In most browsers, we don't want to use cookies for auth state. However, Edge (non-Chromium) needs to
                // leverage cookies for auth state due to security zone issues, else it could end up in auth redirects.
                // More info: https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-js-known-issues-ie-edge-browsers#issues-due-to-security-zones
                storeAuthStateInCookie: browserName === 'edge' ? true : false,
            },
            system: {
                loggerOptions: {
                    loggerCallback: authLoggerCallback,
                    piiLoggingEnabled: false,
                },
            },
        };

Relevant Code Snippets

const account = getActiveAccount();
        const loginHint = account?.username;
        const authority = getAuthority(account?.tenantId);

        const request = { ...defaultSsoRequest, authority, account, loginHint };
        const result = await application.ssoSilent(request);

Reproduction Steps

We are not able to repro this locally but we see it in our logs regularly.

Expected Behavior

SilentSSO returns the appropriate token and the above error is resolved.

Identity Provider

Azure AD / MSA

Browsers Affected (Select all that apply)

Chrome, Firefox, Edge, Safari

Regression

No response

Source

Internal (Microsoft)

[tnorling]

@nipothar This error can be thrown for a number of reasons such as:

1. No user is signed in (if no hint provided) or no user matching the hint is signed-in (if hint provided)
2. No hint is provided but multiple users are signed in (AAD doesn't know which user you intend to sign in with so it throws)
3. The hint provided is in the wrong format or does not match the username of the existing session. (This is mostly relevant in guest user scenarios. Please note that username is the least reliable hint. Use the "loginHint" optional claim (preferred) or "sid" optional claim whenever possible)
4. 3rd party cookies are blocked by the browser

What is the functionality of the loginHint when it comes to calling the ssoSilent requests?

LoginHint is used to tell AAD which account you intend to sign-in with in the case where multiple accounts have active sessions or you require that a specific account be signed in.

Do we need to explicitly set the loginHint if the account is already being sent in the request? If so, what is the reasoning behind this?

No, an account passed in takes precedence. As long as the account has a non-empty "loginHint" claim, "sid" claim or username property those will be used instead of anything passed into loginHint.

Is there anything else missing that you think we need to have that would help us resolve the SSOSilent error?

The code snippets you shared above do not validate that account is not null, nor do they validate the username field is non-empty. This is likely why you are still getting the warning saying no hint is provided. Besides that, please consider using the "loginHint" optional claim as that will give you a higher degree of reliability to disambiguate sessions.

We are already calling acquireTokenRedirect after catching the error, is that the only alternative or is there any way to resolve this bug?

Falling back to interaction is the best way to ensure your user gets signed in and is the recommended approach. You cannot guarantee that you will never encounter this error as things like 3P cookie blocks are not something you can control, but rather are controlled by each user and their browser settings.

[ghost]

@nipothar This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 5 days. If your issue has been resolved please let us know by closing the issue. If your issue has not been resolved please leave a comment to keep this open. It will be closed automatically in 7 days if it remains stale.

[nipothar]

Thanks @tnorling for the information.

I have a few more questions:

1. Where can we get the "loginHint" optional claim from? It looks like the account information does not have that property.
2. You mentioned this could happen if 3p cookies are blocked by browser. My understanding is that the cookies should not make any difference in our case since we disable the cookies and use storage instead in order to get the silentTokens. How does 3p cookies being blocked cause this issue if we have already disabled cookies in our config?

Thanks!

[ghost]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @tnorling please follow up.

[nipothar]

Hi @tnorling, following-up on this. Do you have any updates on the questions above? Thanks!

[tnorling]

@nipothar

1. loginHint is an optional claim that must be enabled on your app registration
2. There are 2 different sets of cookies. The first are temporary cookies used by MSAL.js to keep track of the auth request through the entirety of the request. These are only needed in certain browsers, namely IE11 and Firefox Incognito, and these are the ones you've turned off with the config. The other set of cookies are used by the IDP to keep track of the user's active session, enabling silent sign-in. These are not controlled by you or by MSAL.js and are required for silent sign-in to work. When 3P cookies are disabled by the browser the IDP will not have access to these cookies and throw an error like the one you received.

[ghost]

@nipothar This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 5 days. If your issue has been resolved please let us know by closing the issue. If your issue has not been resolved please leave a comment to keep this open. It will be closed automatically in 7 days if it remains stale.