app.acquire_token_for_client error - AssertionError: Invalid parameter type

[Git-BT-Hub]

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

[JayCork]

I think that the logic from this commit changed scope typing.

[rayluo]

Getting Error on this line, this was working fine until 21-Jul-2023
app.acquire_token_for_client

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.

python -c "from msal import ConfidentialClientApplication as CCA; print(CCA('id', client_credential='foo').acquire_token_for_client('https://graph.microsoft.com/.default'))" 

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]

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 @rayluo said tried to wrap in []
eg.
s = ["https://graph.microsoft.com/.default"]

[Git-BT-Hub]

Getting Error on this line, this was working fine until 21-Jul-2023
app.acquire_token_for_client

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.

python -c "from msal import ConfidentialClientApplication as CCA; print(CCA('id', client_credential='foo').acquire_token_for_client('https://graph.microsoft.com/.default'))" 

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.

Hi @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]

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]

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"]

The scopes parameter 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 like acquire_token_for_client() accidentally allowed string.

Myself and a colleague both have this issue at 2 different clients as of yesterday.

Would you be able to ship your ["scope"] fix with/to your clients? @syntrixsystems

[mkemmerz]

Will the parameter stay a list now or will the change be reverted?

[syntrixsystems]

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"]

The scopes parameter 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 like acquire_token_for_client() accidentally allowed string.

Myself and a colleague both have this issue at 2 different clients as of yesterday.

Would you be able to ship your ["scope"] fix with/to your clients? @syntrixsystems

We both implemented the change in our respective code bases and have had no issues since.

[rayluo]

Will the parameter stay a list now or will the change be reverted?

The scopes parameter 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]

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..

Auto upgrades aside, it is evident that this change was not backwards-compatible, and introduced a breaking change.

[rayluo]

it is evident that this change was not backwards-compatible, and introduced a breaking change.

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]

it is evident that this change was not backwards-compatible, and introduced a breaking change.

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.

I stand corrected; my apologies.