[Microsoft internal] Microsoft tenant forbids accessing Microsoft Graph with browser flow

[jiasli]

Symptom

Recently, Microsoft tenant (72f988bf-86f1-41af-91ab-2d7cd011db47) started to forbid accessing Microsoft Graph (https://graph.microsoft.com/) with browser-based authentication flow (authorization code flow) on Windows.

After running

az config set core.enable_broker_on_windows=false
az login --scope https://graph.microsoft.com//.default --tenant 72f988bf-86f1-41af-91ab-2d7cd011db47

and selecting the @microsoft.com account in the browser, the login page shows error:

Sorry, a security policy is preventing access
An organization security policy requiring token protection is preventing this application from accessing the resource. You may be able to use a different application.

Troubleshooting details:

Error Code: 53003
Request Id: ...
Correlation Id: ...
Timestamp: 2025-03-13T12:31:05.542Z
App name: Microsoft Azure CLI
App id: 04b07795-8ddb-461a-bbee-02f9e1bf7b46
IP address: ...
Device identifier: ...
Device platform: Windows 10
Device state: Compliant

Solution

Enable WAM and run az login:

az config unset core.enable_broker_on_windows
# When you are using an Azure CLI < 2.61.0
# az config set core.enable_broker_on_windows=true
az login --scope https://graph.microsoft.com//.default --tenant 72f988bf-86f1-41af-91ab-2d7cd011db47

[yonzhan]

Thank you for opening this issue, we will look into it.

[ghidalgo3]

@yonzhan this issue is preventing my team from addressing SFI items, because all of our scripts (which call Terraform [which calls the Azure CLI]) are now broken with this kind of error:

│ Error: building account: could not acquire access token to parse claims: running Azure CLI: exit status 1: ERROR: AADSTS530003: Your device is required to be managed to access this resource. Trace ID: 702bcd9d-427b-4fd9-8ecd-9dbd432ba300 Correlation ID: 332f6be3-3c2d-41c9-bdf7-8aaceb93ae42 Timestamp: 2025-08-07 15:56:31Z
│ Run the command below to authenticate interactively; additional arguments may be added as needed:
│ az logout
│ az login --tenant "72f988bf-86f1-41af-91ab-2d7cd011db47" --scope "https://graph.microsoft.com/.default"

If I run az login --scope https://graph.microsoft.com//.default --tenant 72f988bf-86f1-41af-91ab-2d7cd011db47 on any of these platforms:

• macOS
• Windows VM + WSL

I can succesfully login, but I get an error saying my device is not compliant. All of these devices claim they are compliant from MSIT, and if I use the graph explorer I can make graph calls from the machine.

Something about the authentication flow of the Azure CLI is not working, or something about the authentication policies of the Microsoft tenant changed recently, or both. But since I can acccess the Graph API and manage Azure resources through the portal, I'm leaning towards a problem in the authentication libraries used by the Azure CLI.

[jiasli]

@ghidalgo3, This is a Conditional Access policy enforced by MSIT, not Azure CLI. This is not under Azure CLI's control.

Currently, if you want to access Microsoft Graph with Azure CLI and a user credential, you have to use Windows and WAM (az config set core.enable_broker_on_windows=true, which is the default).

Another workaround is to use service principal to access Microsoft Graph.

[ghidalgo3]

@jiasli I know the Azure CLI team doesn't control MSIT policies, but teams all over Microsoft use the Azure CLI to manage Azure resources and they have to use the Azure CLI to do so. If MSIT's policy changes break functionality of the Azure CLI (specifically the form of authentication tokens acquired), then Azure CLI needs to upgrade its auth library to allow us to comply.

Apart from these GitHub issues and my own experimentation, I have found no authoritative documentation saying that Az CLI on macOS will not work with MSIT's Conditional Access policies. I think the problem does lie with the Azure CLI because I can access Microsoft Graph from a browser on a mac, but not through the Az CLI. What is different about the token my browser acquires vs. the token the Az CLI acquires?

Regarding service principals, we have been phasing out using service principals because they require creating secret credentials, which is no longer allowed by MSIT.

[matt-chan]

While azcli might be able to implement another auth method, I needed a workaround now to keep working.

I found this Sharepoint site describing the policy and exception process: https://microsoft.sharepoint.com/sites/Identity_Authentication/SitePages/CoreIdentity/TokenProtection-FAQ.aspx#troubleshooting

• go to tech web helpdesk
• start a virtual agent chat
• type "I need a real person"
• Mention "Token Protection" in your ticket description
• They will ask for an error message showing "AADSTS530084"
• They will whitelist your account in the backend. It should only take a minute or two to take effect.