{Auth} Remove broker_error detection for re-authentication message#31743
{Auth} Remove broker_error detection for re-authentication message#31743
broker_error detection for re-authentication message#31743Conversation
️✔️AzureCLI-FullTest
|
️✔️AzureCLI-BreakingChangeTest
|
|
Update re-authentication message |
|
The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR. Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions). pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>
|
microsoft-github-policy-service
bot
added
the
ARM
| recommendation = ( | ||
| # Cloud Shell uses IMDS-like interface for implicit login. If getting token/cert failed, | ||
| # we let the user explicitly log in to AAD with MSAL. | ||
| "Please explicitly log in with:\n{}" if error.get('error') == 'broker_error' |
There was a problem hiding this comment.
In Cloud Shell, az account get-access-token --scope non-existing triggers a {'error': 'AudienceNotSupported', 'error_description': 'Audience non-existing is not a supported MSI token audience.'}.
error.get('error') == 'broker_error' does not match this error.
There was a problem hiding this comment.
I agree with this PR. Here comes more context about the "broker_error", for posterity.
-
In MSAL's underlying implementation, the
{"error": "broker_error", ...}was a necessary placeholder to normalize Cloud Shell's potential "deceivingly successful token response containing a mismatching token type" situation. It happened that the "broker_error" value was chosen (rather than inventing a "cloud_shell_error"). -
Now looking back, if this error handling snippet in Azure CLI was meant to pinpoint that corner case, it should have used a more precise condition, something like this:
recommendation = ( """You are using Cloud Shell and it does not yet support this token type request. Please explicitly log in with: {}""" # But I don't quite remember whether an "az login --identity" would make a difference here if in_cloud_console() and error.get('error') == 'broker_error' else "Interactive authentication is needed. Please run:\n{}" ).format(login_command)
-
Now that the differentiation in
#2is no longer needed, yes let's simplify the implementation here to remove that "A if condition else B" usage. This change feels right because, even though an interactive login will NOT address all errors (certainly not the--scope NON-EXISTwrong usage), but at least the end user shall get a better error UI when interacting with Entra ID web pages.
There was a problem hiding this comment.
if this error handling snippet in Azure CLI was meant to pinpoint that corner case
Yes. The error handing is indeed to pinpoint Cloud Shell's potential "deceivingly successful token response containing a mismatching token type" situation, so we can use if in_cloud_console() and error.get('error') == 'broker_error to still handle this error.
In the latest Cloud Shell, this error is no longer reproducible:
cli.azure.cli.core.auth.credential_adaptor: CredentialAdaptor.get_token: scopes=('https://pas.windows.net/CheckMyAccess/Linux/.default',), kwargs={'data': {'token_type': 'ssh-cert', ...
cli.azure.cli.core.auth.msal_credentials: CloudShellCredential.acquire_token: scopes=['https://pas.windows.net/CheckMyAccess/Linux/.default'], kwargs={'data': {'token_type': 'ssh-cert', ...
urllib3.connectionpool: Starting new HTTP connection (1): localhost:50342
urllib3.connectionpool: http://localhost:50342 "POST /oauth2/token HTTP/1.1" 200 2085
msal.token_cache: event={
"authority_type": "CLOUDSHELL",
"client_id": "04b07795-8ddb-461a-bbee-02f9e1bf7b46",
"data": {
...
"token_type": "ssh-cert"
},
"response": {
...
"token_type": "ssh-cert"
},
"scope": [
"https://pas.windows.net/CheckMyAccess/Linux/.default"
],
"token_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/token"
}
cli.azext_ssh.custom: Generating certificate /tmp/aadsshcertddj67t98/id_rsa.pub-aadcert.pub
The token_type in the response does match the token_type in the request, so there is no need to keep this error handing logic.
| # we let the user explicitly log in to AAD with MSAL. | ||
| "Please explicitly log in with:\n{}" if error.get('error') == 'broker_error' | ||
| else "Interactive authentication is needed. Please run:\n{}").format(login_command) | ||
| recommendation = ("Interactive authentication is needed. " |
There was a problem hiding this comment.
Without broker, the raw MSAL error (retrieved with #31746) in az account get-access-token --tenant 54826b22-38d6-4fb2-bad9-b7b93a3e9c5a --debug is
{
"error": "invalid_grant",
"error_description": "AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '797f4846-ba00-4fd7-ba43-dac1f8f63013'. Trace ID: 660478d8-34f9-4df6-ad18-d944abab5100 Correlation ID: 6a3b809c-592f-4dd4-8a2f-30e7fe643309 Timestamp: 2025-07-02 09:02:58Z",
"error_codes": [50076],
"timestamp": "2025-07-02 09:02:58Z",
"trace_id": "660478d8-34f9-4df6-ad18-d944abab5100",
"correlation_id": "6a3b809c-592f-4dd4-8a2f-30e7fe643309",
"error_uri": "https://login.microsoftonline.com/error?code=50076",
"suberror": "basic_action",
"classification": "basic_action",
}
With WAM, the raw MSAL error in az account get-access-token --tenant 54826b22-38d6-4fb2-bad9-b7b93a3e9c5a --debug is
{
"error": "broker_error",
"error_description": "SubError: basic_action V2Error: invalid_grant AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '797f4846-ba00-4fd7-ba43-dac1f8f63013'. Trace ID: 2cabc6ba-9c4d-403c-8341-ce0d629a0000 Correlation ID: 23cddf21-bd93-4b5d-96f1-7b5bb91fbba8 Timestamp: 2025-07-02 09:16:06Z. Status: Response_Status.Status_InteractionRequired, Error code: 3399614476, Tag: 557973645",
"msal_telemetry": '{"msalruntime_telemetry":{"DATA LIMITED":"Full MSALRuntime telemetry not yet implemented","api_error_context":"Error context redacted, value may be written to log.","api_name":"AcquireTokenSilently","api_status_code":"StatusInternal::InteractionRequired","broker_app_used":"true","client_id":"04b07795-8ddb-461a-bbee-02f9e1bf7b46","correlation_id":"23cddf21-bd93-4b5d-96f1-7b5bb91fbba8","is_successful":"false","msal_version":"1.1.0+local","msalruntime_version":"0.18.1"},"msal_python_telemetry":null}',
}
Response_Status.Status_InteractionRequired is only mentioned in the WAM flow, so we have no way to tell if interaction is required.
jiasli
changed the title
broker_error detection for re-authentication message
7 participants
Related command
az loginDescription
Previously,
broker_erroris dedicated to denote getting VM SSH certificate error in Cloud Shell (#22162) and the re-authentication message (error recommendation) is:This is because in Cloud Shell, Azure CLI is implicitly authenticated and no explicit
az login --identityis required.On a local machine, the re-authentication message for Entra errors is
After supporting Windows broker (#23828), an Entra error such as
AADSTS50076is also returned asbroker_errorin theerrorproperty of the MSAL result, making it impossible to tell if the error is from Cloud Shell or Entra. The re-authentication message for Entra errors is alsowhich is inaccurate.
This PR drops the
broker_errordetection logic and unifies the re-authentication message.As it has been years since Cloud Shell supported getting VM SSH certificate, the error is not likely to happen anymore.
Testing Guide