AADSTS65004: User declined to consent to access the app

What does AADSTS65004 mean?

Microsoft’s description:

UserDeclinedConsent: User declined to consent to access the app. Have the user retry the sign-in and consent to the app

The app sent the user to a consent prompt and came back without a grant. In the OAuth authorization code flow, Microsoft lists the matching protocol error as access_denied, “Resource owner denied consent”, and says “The client application can notify the user that it can’t continue unless the user consents.”

What is the quick fix?

First work out which of two cases you are in:

• The user just submitted an admin consent request. Microsoft documents this as expected: “After a user submits an admin consent approval for an application, another dialog appears with a Back to app button. When the user selects the button, Microsoft Entra ID sends an AADSTS65004 error to the redirect URI specified in the original authentication request. This error is an expected part of the admin consent workflow.” Wait for the reviewer. After approval, “the user needs to begin a new authentication process with the application.”
• The user said no at the prompt. If the app is one you trust, have the user sign in again and accept, as Microsoft’s description says.

If the user can’t accept because the permissions need an admin, that is a different code: 90094, or 90095 with the admin consent workflow on.

Is it an attack?

No, not on its own. 65004 is the absence of a grant. The risky moment in consent phishing is a grant that does happen. Microsoft describes the attack: the attacker “tricks an end user into granting that application consent”, and after that the app “has account-level access to data without the need for an organizational account.” The consent phishing guide covers that investigation.

Pattern	Likely meaning
65004 shortly after 90095 for the same user and app	The admin consent workflow as documented. Benign.
65004 for a known app, then a success after the user retried	The user cancelled once, then accepted. Benign.
65004 for an app ID you don’t recognise, from several users	Users were sent to an app nobody approved, and some said no. Check whether others said yes.

The second and third rows are reasoning from what the code means, not Microsoft detections.

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

65004 per app, with how many of those users also hit 90095 (the admin consent workflow) for the same app:

let window = 7d;
let declines =
    SigninLogs
    | where TimeGenerated > ago(window)
    | where ResultType == "65004"
    | project DeclineTime = TimeGenerated, UserPrincipalName, AppId, AppDisplayName, IPAddress;
let requests =
    SigninLogs
    | where TimeGenerated > ago(window)
    | where ResultType == "90095"
    | distinct UserPrincipalName, AppId
    | extend RequestedAdminConsent = true;
declines
| join kind=leftouter requests on UserPrincipalName, AppId
| summarize Declines = count(),
            Users = dcount(UserPrincipalName),
            UsersWithAdminRequest = dcountif(UserPrincipalName, RequestedAdminConsent == true),
            FirstSeen = min(DeclineTime)
          by AppId, AppDisplayName
| sort by Users desc

Apps where Users is much larger than UsersWithAdminRequest are the ones where people said no at the prompt. For an app you don’t know, check the 65001 page query to see whether anyone later consented.

ResultType is a string column, so compare it with "65004", not 65004.

How do Conditional Access and consent settings affect it?

• 65004 isn’t caused by Conditional Access. It is a consent decision.
• With user consent restricted, a user who can’t grant the permissions gets 90094. With the admin consent workflow on, they get 90095, can send a request, and the Back to app step then returns 65004.
• Microsoft notes that users can’t grant consent to apps Microsoft detects as risky. Admins can, but Microsoft says they “should evaluate the app carefully and proceed with caution.”

How do I fix AADSTS65004?

For the user: if you just sent an admin consent request, wait for approval and then sign in to the app again. If you cancelled by mistake and trust the app, sign in again and accept.

For developers: handle access_denied by telling the user the app can’t continue without consent, as Microsoft recommends.

For admins:

1. Check whether the 65004 followed a 90095 for the same user and app. If yes, review the pending request.
2. If the app is approved for the organization, grant admin consent so users don’t see the prompt.
3. For an app you don’t recognise, find who published it and what it asks for before anyone consents.