AzureCliCredentials throws an exception on invalid data when parsing the token in Windows

[yogilad]

• Azure.Identity:
• 1.5.0:
• Windows 10:
• 3.9.2:
• Microsoft Azure Cli version 2.0.80

Describe the bug
When trying to obtain a token using AzureCliCredential I get an error saying the token returned from Az is invalid.
Issue seems to lie in some extra characters of unknown origin.

Example of token produced by the library call to account get-access-token
8th line has an ESC char followed by some unknown characters

{
  "accessToken": "eyJ********",
  "expiresOn": "2021-05-12 14:58:55.021835",
  "subscription": "7a7b5559-58af-401a-b543-61b7321a97ea",
  "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db47",
  "tokenType": "Bearer"
}
**�[0m**

To Reproduce
Hard to say why this fails. Code is basically

self._kusto_uri = "https://kusto.kusto.windows.net"
self._az_auth_context = AzureCliCredential()
msi_token = self._az_auth_context.get_token(self._kusto_uri)

Expected behavior
Well, this ought to produce a valid token :)

Screenshots

Additional context
None

[chlowell]

This looks like #11362. The gist of that is, the Azure CLI adds those extra characters to color output. When you use AzureCliCredential in some terminals, in particular PyCharm's, they appear in the subprocess's stdout, making it invalid JSON. Azure CLI added an environment variable applications can set to disable output coloring in its version 2.3.0 or thereabouts, which AzureCliCredential sets to prevent this problem. I see you're using Azure CLI 2.0.80--can you update to a newer version and try again?

[yogilad]

That seems to be the issue.
An upgrade resolved the problem.
Thanks!

[yogilad]

P.S.
Reading the code, I don't see any cache level in AzCliCredential.
Since you execute a program to get the token, it would significantly slow down scripts that use it repeatedly.
You may want to cache the token for up tp 10 minutes or so before its expires.

[chlowell]

Glad that worked, I'll close this issue then. You're correct that AzureCliCredential caches nothing, every get_token() invokes the CLI, ensuring the credential always reflects the login state of the CLI. That does make get_token() expensive but in typical usage, i.e. through an Azure SDK client, it isn't a problem because our clients do what you suggest.