Repository navigation
app.acquire_token_for_client error - AssertionError: Invalid parameter type #583
Description
Getting Error while trying to acquire Token using below
from msal import ConfidentialClientApplication
#import secrets from keyvault
service_principal_id = dbutils.secrets.get(scope = secret_scope, key = "clientid")
service_principal_secret = dbutils.secrets.get(scope = secret_scope, key = "clientsecret")
tenant_id = dbutils.secrets.get(scope = secret_scope, key = "tenant-id")
authority = "https://login.windows.net/" + tenant_id
app = ConfidentialClientApplication(
client_id=service_principal_id,
client_credential=service_principal_secret,
authority=authority
)
s = "https://graph.microsoft.com/.default"
result = app.acquire_token_for_client(scopes=s)
a = result.get("access_token")
print(a)
Getting Error on this line , this was working fine until 21-Jul-2023
app.acquire_token_for_client
Please let me know what has changed in MSAL(PYPI) or what is the alternative with latest version
If this can work with Previous Version let me know, which version to use
Thanks
Activity
JayCork commentedon Jul 24, 2023
I think that the logic from this commit changed scope typing.
rayluo commentedon Jul 24, 2023
Out of curiosity, does your environment somehow always pull in the latest MSAL version, unknowingly? Most bug reports would pinpoint the differences as either "this was working until I upgrade to your new version X.Y.Z" or "this was working until I made a change in the code snippet" etc..
That being said, lucky that in this case, yes we can correlate the timing with our recent release of MSAL 1.23. Indeed, the following line works with MSAL 1.22 but can repro your error in MSAL 1.23.
We shall probably improve that exception message in the future. Meanwhile, as hinted by the line number in that exception, the error was about the scope input was meant to be a list, not a string.
If at all possible, please change your
"scope"to["scope"], and then stay with latest MSAL 1.23.By the way, is your app a long-lived daemon, or a one-time command-line tool? If it is the latter, you shall further consider to enable a token cache, otherwise your app risks being throttled if/when it sends out too much token requests.
p17b commentedon Jul 24, 2023
had the same issue with release 1.23.0, was ok in 1.22.0
I found that the 'scopes' parameter should be a list of strings.
as Ray Luo (@rayluo) said tried to wrap in []
eg.
s = ["https://graph.microsoft.com/.default"]Git-BT-Hub commentedon Jul 24, 2023
Hi Ray Luo (@rayluo) - Thats correct, I always get latest version on MSAL, but after this error when I switched to v1.22, it seems to be working fine . I will try converting "scope" to ["scope"], and see if that works for me. [I am using Azure Databricks]
Thanks
syntrixsystems commentedon Jul 24, 2023
Myself and a colleague both have this issue at 2 different clients as of yesterday.
My colleague noted just now that if you enclose the scopes value in brackets, seems to have resolved the issue for us. scopes must be expecting a list now?
token = app.acquire_token_for_client(scopes=["https://database.windows.net/.default"])["access_token"]
rayluo commentedon Jul 24, 2023
The
scopesparameter was meant to be a list of strings, as all other acquire token APIs do. Our docs said so for the last 5 years. Looks likeacquire_token_for_client()accidentally allowed string.Would you be able to ship your
["scope"]fix with/to your clients? Syntrix Systems Inc. (@syntrixsystems)mkemmerz commentedon Jul 25, 2023
Will the parameter stay a list now or will the change be reverted?
syntrixsystems commentedon Jul 25, 2023
We both implemented the change in our respective code bases and have had no issues since.
rayluo commentedon Jul 25, 2023
The
scopesparameter has always been a plural, so it is meant to accept a list of strings. This part will never change.Even if we might bring back the "scopes as a string" usage, it will not be a revert. It will be with a DeprecationWarning. So, you are still recommended to switch to the list-of-string syntax, in order to be future proof.
disciple-dev commentedon Jul 26, 2023
Auto upgrades aside, it is evident that this change was not backwards-compatible, and introduced a breaking change.
rayluo commentedon Jul 26, 2023
To set the record straight, the concept of backwards-compatible or breaking-change does not apply to implementation details. In this case, the docs and the sample have all been a list of strings for 4 or 5 years. There is also the 2nd bullet point here saying that the undocumented behaviors are subject to change without prior notice.
disciple-dev commentedon Jul 26, 2023
I stand corrected; my apologies.