acquire_token_interactive() never returns when user does not have access [Bug]

[craigwalton]

Describe the bug
Calling PublicClientApplication.acquire_token_interactive() when the user does not have access to the resource shows an error in the browser, but the acquire_token_interactive() method does not return an error - it remains in the time.sleep(1) loop indefinitely (even if the browser window is closed). Ctrl+C terminates the process.

To Reproduce

1. Use https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/dev/sample/interactive_sample.py
2. Configure as

{
    "authority": "https://login.microsoftonline.com/organizations",
    "client_id": "37b12803-e95b-4e78-9a16-e01706d75b3c",
    "scope": ["User.ReadBasic.All"],
    "endpoint": "https://graph.microsoft.com/v1.0/users"
}

Note: The client ID is an internal proof-of-concept Azure AD application.
3. Run the sample python interactive_sample.py config.json
4. The browser opens and informs the user that they don't have access. There is no "continue" or "exit" button.

5. The script continues running indefinitely, without erroring.

Expected behaviour
acquire_token_interactive() returns a dict containing an error_description.

What you see instead

python .\interactive_sample.py .\config.json    
A local browser window will be open for you to sign in. CTRL+C to cancel.

Ctrl+C terminates the process with a stack trace pointing to time.sleep(1).

The MSAL Python version you are using
1.25.0

Additional context
Windows 10. Default browser Chrome. Python 3.11. Running from VS Code terminal.
Not configured to use broker on windows.

I believe the Azure AD side of things is configured correctly with respect to redirect URLs - when I am granted permissions, the browser shows success and the acquire_token_interactive() returns with a valid access_token.

Some errors shown in the browser do result in acquire_token_interactive() with an error, e.g. requesting a non-existent scope api://37b12803-e95b-4e78-9a16-e01706d75b3c/fake-scope.

Our workaround is to set the timeout parameter, despite #516 recommending against this in interactive auth flows, and the resulting error just being an AssertionError.

Please accept my apologies if this isn't an issue with the MSAL Python library, or if we've misconfigured our Azure AD application.

[bgavrilMS]

This is by design @craigwalton - most config errors are displayed to the user instead of being relayed back to the app. There is nothing your application can do at runtime with the error information there, except to display some generic "Can't login" which is not ideal.

Also, when you say "there is no exit or continue" button, please note that the end-user can close the browser. WIth the system browser, MSAL can't know when the browser is closed.

With WAM, the end-user experience is better, because you'll get an "auth cancelled" error whenever the user closes the interactive experience, so you are at least able to monitor cancellations.

[craigwalton]

Thank you very much for clarifying this so promptly @bgavrilMS . This all makes sense.

Yes, I appreciate that using WAM results in a better UX and the cancellation error. Unfortunately, we haven't been able to come up with a reliable way of obtaining a suitable Windows HWND to pass to MSAL given our library is expected to be run in numerous different environments and we're hesitant about requiring our library users to provide a HWND.

Thanks again!

[rayluo]

Yes, I appreciate that using WAM results in a better UX and the cancellation error. Unfortunately, we haven't been able to come up with a reliable way of obtaining a suitable Windows HWND to pass to MSAL given our library is expected to be run in numerous different environments and we're hesitant about requiring our library users to provide a HWND.

Thanks for sharing your thoughts with us, @craigwalton . MSAL Python is more or less in the same boat here. If you come up with a decision/solution for the HWND, feel free to let us know.

[craigwalton]

Just in case this is of interest to you or other readers:

In the meantime, we've opted to:

• first try to acquire a token silently* using the a broker-enabled PublicClientApplication
• if that requires user interaction, fall back to using a PublicClientApplication without broker (i.e. via browser).

*We prevent the broker from becoming interactive by either by:

• setting prompt="none" in acquire_token_interactive() OIDC Spec or
• by raising an exception (which we catch) via the on_before_launching_ui callback. We pass in the useful PublicClientApplication.CONSOLE_WINDOW_HANDLE as the parent_window_handle, despite knowing it will never be used.

This is a similar approach to what we've taken in another library which uses MSAL for .NET. We've again sidestepped the need to provide a HWND. The main difference being that the .NET MSAL library has explicit support for acquiring a token silently from the broker via PublicClientApplication.AcquireTokenSilent(<scopes>, PublicClientApplication.OperatingSystemAccount). It raises an MsalUiRequiredException when it needs interaction, in which case we fall back to a non-broker approach.

Thanks again for your suggestions and support.

[rayluo]

The new conversation goes well beyond the scope of the original issue, so I put it into a separate conversation there. Locking this issue now.