New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Acquiring token silently with account set to None fails in Azure Government #223
Comments
|
Thanks for following our issue template, @marlonsingleton ! Your code snippet happened to supply a list for the
Perhaps you can send us your full error trace (which would typically contain only script file names and line numbers, but no other sensitive info) to understand what happened. That starting (?) line Regardless, the ending error |
|
I tried to reproduce this error and was able to get it reproduced. What I found out is, in the acquire_token_silent call, the step where authority aliasing is performed, there is an alias returned for login.microsoftonline.us which is |
|
After investigating looks like there is SSL validation failure from |
|
MAG customer who filed the original bug report with MAG support here.
Confirmed, that was a typo from my original repro code. The original was And to confirm, I am also seeing the TLS validation failure. The |
|
@abhidnya13 thanks! I was also able to repro before posting this issue. Any thoughts why acquire_token_for_client(scopes=SCOPES) returns a bearer token? |
|
@marlonsingleton acquire_token_silent(...) performs authority aliasing which basically means it tries to see if there is a token in the cache for the input authority and if we can't find one using the input authority, all its authority aliases are used to search for a token. In the case of login.microsoftonline.us the server returns the alias login.usgovcloudapi.net and so when when this authority is initialized, it does network calls at which the SSL validation failure happens. This type of aliasing is not done for acquire_token_for_client() scenarios and so the token is successfully returned. |
|
Closing notes: This was triggered by multiple reasons combined. Now a workaround has been shipped in MSAL Python 1.4.2. |


Describe the bug
A clear and concise description of what the bug is.
UPDATE by Ray: There is also an internal issue created here, which is currently under investigation by our service side team.
To Reproduce
Steps to reproduce the behavior:
config.jsoncontaining your test configurationspython sample.py config.jsonExpected behavior
What you see instead
The MSAL Python version you are using
Paste the output of this
python -c "import msal; print(msal.__version__)"MSAL version '1.4.1'Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: