AADSTS7000110: Code or refresh token used by a different app (fix)

What does AADSTS7000110 mean?

Microsoft’s error code reference doesn’t list AADSTS7000110 (checked 30 October 2026).

Microsoft documents it in a troubleshooting article. The message:

Request is ambiguous, multiple application identifiers found. The client ID used to obtain the grant (e.g. refresh token or authorization code) might not match the client ID passed in this request or client credential.

Microsoft’s cause: the application tried to

• Redeem an OAuth2 authorization code to get an access token or a refresh token that has the wrong application ID (client_id parameter).
• Use a refresh token that was initially issued to the application ID of a different caller.

An authorization code or refresh token belongs to the app that requested it. If the token request names another app, Entra sees two app IDs and refuses. The “client credential” part of the message suggests a third variant. Our reading: a confidential client whose secret or certificate belongs to a different app registration than the client_id. Microsoft’s article doesn’t list that case.

Is it an attack?

Usually not. It is a config mix-up.

Pattern	Likely meaning
Fails right after a code is returned to the app	The authorize request and the token request use different client IDs. Common when an app has separate dev and prod registrations.
A refresh token stored by one app is reused by another	Probably two apps share a token cache or a database table (unconfirmed).
Fails after an app registration was replaced	Stored refresh tokens still belong to the old app ID. Users have to sign in again.
Refresh tokens for your users presented from IPs and user agents your apps don’t use	Our interpretation: someone may be replaying a token captured from one app under another client ID. Check the IPs before dismissing it.

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

Microsoft doesn’t document which sign-in table 7000110 is logged in. Check where it lands in your workspace:

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

Which apps, and from where. Many users on one app is a config bug. One user from an unfamiliar IP is worth a closer look:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "7000110"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            IPs = make_set(IPAddress, 10),
            UserAgents = make_set(UserAgent, 5),
            FirstSeen = min(TimeGenerated)
          by AppDisplayName, AppId
| sort by Users asc

Our reading: the AppId in the row is probably the client ID that was sent in the token request, not the one the token was issued to. That isn’t documented. Non-interactive rows are aggregated, so counts are not request counts.

How do I fix AADSTS7000110?

For the user: sign out of the app and sign in again. If it keeps happening, report it to the app’s owner.

For developers:

1. Microsoft’s fix: “Use an OAuth2 authorization code or a refresh token that’s from the same application ID (client_id parameter).”
2. Check that the authorize request and the token request read the client ID from the same setting. Look for a dev client ID in one place and a prod one in another.
3. Keep refresh tokens per app. Don’t share a token cache between two app registrations.
4. For a confidential client, check that the secret or certificate belongs to the same app registration as the client_id. This step comes from the message’s “client credential” wording, which Microsoft doesn’t explain.
5. After replacing an app registration, clear the stored refresh tokens and send users through sign-in. Microsoft’s refresh token page says apps should handle revoked tokens “by redirecting the user to an interactive sign-in prompt”.

For admins:

1. Find the app in the second query and give the developer its AppId, plus the app ID they expected.
2. If the rows come from IPs or user agents that none of your apps use, treat it like a suspicious token use. Look at the same user’s successful non-interactive sign-ins from those IPs.