AADSTS90133: Device code flow not supported on /common or /consumers (fix)

What does AADSTS90133 mean?

Microsoft’s error code reference doesn’t list AADSTS90133 (checked 30 October 2026). The nearest listed code is AADSTS90130: “The application isn’t supported over the /common or /consumers endpoints.”

Microsoft does mention 90133 elsewhere. The .NET sample in its device code flow article for desktop apps lists it in a code comment, with the fix:

// AADSTS90133: Device Code flow is not supported under /common or /consumers endpoint.
// Mitigation: as explained in the message from Azure AD, the authority needs to be tenanted

“Tenanted” means the sign-in URL names your tenant, by ID or domain, instead of common or consumers. The same sample uses https://login.microsoftonline.com/contoso.com as its authority.

This is a code comment, not a reference entry. Microsoft’s device code protocol page says something broader. It says the {tenant} value “Can be /common, /consumers, or /organizations”, or a tenant ID or domain. Our reading: the two pages don’t contradict each other if 90133 applies only to some apps, but Microsoft doesn’t say which ones. Treat the code comment as the documented trigger and the exact conditions as unknown.

We tried to reproduce it on 30 October 2026. A lab run requested a device code on /consumers with an app registered for work accounts only. Entra didn’t return 90133. It returned AADSTS700016 instead:

AADSTS700016: Application with identifier ‘{app-id}’ was not found in the directory ‘{tenant-id}’.

Our reading: on /consumers Entra looked for the app in a directory that isn’t our lab tenant and didn’t find it. In that one run, 700016 came back before any 90133 check. We haven’t found the setup that returns 90133. See how pages are checked.

Is it an attack?

No. Microsoft’s comment points to a configuration error in the app or script that starts the device code flow. The device code request is the first step of the flow, before any user signs in.

Pattern	Likely meaning
A new CLI tool or script fails on its first run	The authority is /common or /consumers. Use your tenant ID or domain.
A tool works for one tenant and fails after a config change	Someone replaced the tenant ID with a generic endpoint. Likely, but unconfirmed.
A vendor tool fails for every customer	The vendor’s default authority is generic. Ask for a tenant setting.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 90133 is logged in. Probably no row is written in your tenant: the request fails before a user signs in, and /common and /consumers don’t name your tenant. Check anyway; this query is expected to return nothing:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "90133"
| summarize Rows = count() by SourceTable

How do I fix AADSTS90133?

For the user: you can’t fix this. Tell whoever runs the tool that its sign-in setting needs your tenant ID.

For developers:

1. Use a tenant-specific authority for device code flow, as Microsoft’s comment says: https://login.microsoftonline.com/<tenant id or domain>.
2. Use the same value for the device code request (/oauth2/v2.0/devicecode) and the token polling request (/oauth2/v2.0/token). Microsoft’s protocol page says the polling request must use “the same tenant or tenant alias used in the initial request.”
3. If the tool serves many tenants, make the tenant a setting instead of hard-coding common.

For admins: give the tool your tenant ID. Our AADSTS90002 page shows how to find it.