AADSTS65001 and AADSTS90094: the app needs user or admin consent first

Fix it now

Nobody has agreed to let the application use the permissions it is asking for, so Entra ID has no grant to issue a token against. AADSTS90094 is the narrower and more final version: those permissions can only be granted by an administrator, so the user cannot get past it however many times they retry. Somebody with the right role has to read the permission list and decide.

1. Note the application name and the exact permissions shown on the consent screen or in the error detail before you change anything.
2. In the Microsoft Entra admin center, open Enterprise apps, find the application, select Permissions and review the requested list line by line.
3. Grant admin consent for the tenant only once you are satisfied each permission is justified by what the application does. Admin consent applies to every user in the tenant, not just the person who reported the error.
4. If the application has no enterprise application entry yet, drive consent from the admin consent endpoint instead, signing in as an account whose role permits tenant-wide consent.
5. If you should not be the one deciding, turn on the request workflow: Entra ID then Enterprise apps then Consent and permissions then Admin consent settings, and set users to be able to request admin consent to apps they cannot consent to. Global Administrator is the documented prerequisite for switching it on.
6. Retry the sign-in. A correctly consented application should not show a consent screen again.

Prefer granting consent for one application over loosening the tenant-wide user consent policy. The policy is the main defence against a convincing-looking application harvesting mailbox access one user at a time.

If the user reaches the application without a prompt, you are done. If they still cannot, the next section covers what consent actually records and who is allowed to create it.

Why it happens

Consent is a stored object, not a setting. When someone agrees, Entra ID writes a grant linking the client application to the resource it wants to call and the specific scopes it asked for. That grant is either for one user, which is what happens when a user consents for themselves, or for the whole tenant, which is what admin consent creates. AADSTS65001 is published as DelegationDoesNotExist: the user or administrator has not consented to use the application, and the remedy Microsoft names is an interactive authorisation request for that user and resource.

Whether an ordinary user may create a grant at all is a tenant setting. Many organisations restrict user consent, either disabling it outright or permitting it only for applications from verified publishers and only for permissions classified as low impact. That is a defensible security decision and this error is its predictable side effect. It is the mechanism that stops a plausible-looking application collecting mailbox access one user at a time, and turning it fully open to make an error message go away trades that protection for convenience.

AADSTS90094 sits outside any tenant setting. Some permissions are administrator-only by definition, including anything that reads or writes data across the whole organisation, and no user consent screen is ever offered for those. AADSTS650056 points somewhere else again: it means the application is misconfigured, and Microsoft lists four distinct causes under it, so it is worth reading properly rather than assuming the first one.

Full reference

Working out who is blocked and why

Turning on the request workflow

Rather than leaving people at an error page, the tenant can let them raise a request that routes to named reviewers. Microsoft’s documented prerequisites are an Azure account and Global Administrator to switch it on, and the path is Entra ID then Enterprise apps then Consent and permissions then Admin consent settings, where you set users to be able to request admin consent to apps they are unable to consent to.

• Choose the reviewers deliberately. Anyone who can approve a consent request can grant tenant-wide access.
• AADSTS90095 is what users see when the workflow interrupts them to ask an administrator, so it is a sign the mechanism is working rather than a failure.
• Reviewing a request is the same decision as granting consent directly; the workflow adds a record and a queue, not a safety net.
• Keep the request queue short. A backlog turns into blanket approvals, which is worse than having no workflow at all.

Before you grant anything

1. Read every permission on the list, not the first two.
2. Check the publisher, and whether it is a verified publisher.
3. Ask whether the application needs organisation-wide read or write, or whether a narrower delegated permission would do.
4. Prefer assigning the application to the group that needs it over leaving it open to everyone.
5. Record who approved it and why, because admin consent is tenant-wide and quiet.

Revoking consent afterwards

Consent can be removed: take the permissions off the enterprise application, or delete the enterprise application entirely. What removal does not do is invalidate tokens that have already been issued, and those remain valid until they expire. If you are revoking consent as part of an incident rather than as housekeeping, revoke the affected users’ sessions as well, and treat the two as one action rather than two.

Where the audit trail lives

• The application’s Permissions page lists both admin-granted and user-granted permissions.
• The audit log records every consent event with the account that performed it.
• A permission that appears on the page but not in the audit log was granted before your retention window, not by nobody.
• Check both after granting consent, so the record exists before anyone needs it.
• If a permission appears that you did not grant, treat it as an incident rather than as a configuration surprise.

Every code this article covers

Confirm the fix worked

1. The application’s Permissions page lists the scopes as granted for the tenant, with the granting account recorded.
2. The user who reported the error signs in and reaches the application with no consent prompt.
3. A second user in a different group also completes the sign-in, which confirms the grant is tenant-wide rather than per user.
4. The audit log shows a consent event at the time you granted it, and nothing unexpected afterwards.
5. If you turned on the request workflow, a test request reaches the reviewers you nominated.

Questions people ask about this