Closed jiasli closed 2 years ago
My brain was not sharp when you brought this up in our ad-hoc meeting yesterday (mid-night time here in Redmond). Now I can answer them better.
Goal
Suppose we don't have interest in supporting auth code flow in a docker container, and we just want to automatically fall back to device code flow.
Actually, we do have interest in supporting auth code flow as much as possible, even including some situations that were not previously considered possible. We will discuss more on those challenges in separate topics.
Therefore, MSAL's acquire_token_interactive()
does not aggressively error out. That is also why you would observe the following symptom.
Currently in MSAL-based CLI, running
az login
in docker will hang, as MSAL doesn't throw an exception when it fails to open a web browser....
The "hang" is kind of intentional, to allow some potential hack to make it work, such as the docker --net=host ...
situation, which we will discussed in depth in a different conversation. If MSAL would error out aggressively, you won't have a chance to make it work.
In other words, MSAL's acquire_token_interactive()
considers its main job as starting a mini http server and waiting for the auth response to come back. Whether a browser can be launched in the current environment is not necessarily a prerequisite. In fact, MSAL could just print the URL for the user to manually open it in their browser. As long as the auth response can somehow reach back to MSAL, acquire_token_interactive()
would work.
I understand it is possible to throw an Exception at
But I am not sure if this is a good choice and the correct usage of
auth_uri_callback
.
Yes, it is! The main reason auth_uri_callback
exists, is designed to allow you to raise exception, therefore opt out of the auth code flow. :-)
Goal
Suppose we don't have interest in supporting auth code flow in a docker container, and we just want to automatically fall back to device code flow.
Symptom
Currently in MSAL-based CLI, running
az login
in docker will hang, as MSAL doesn't throw an exception when it fails to open a web browser.On the other hand, in ADAL-based CLI, if CLI fails to open a web browser, it throws
RuntimeError
and falls back to device code flow:https://github.com/Azure/azure-cli/blob/14cc787d0f58bc649d402b486fdecc5625eee9ac/src/azure-cli-core/azure/cli/core/_profile.py#L199-L205
I understand it is possible to throw an Exception at
https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/0deba2e88a9595986282b14ce03a57bc9dc0539c/msal/oauth2cli/authcode.py#L253
But I am not sure if this is a good choice and the correct usage of
auth_uri_callback
.To Reproduce