AADSTS90094 persists for delegated users despite tenant-wide admin consent verified via Graph API — request consent-cache / per-user state inspection

Bon 0 Reputation points
2026-05-28T17:21:25.0233333+00:00

We are blocked at the Microsoft sign-in step with AADSTS90094 ("Admin consent is required") for a delegated OAuth flow on non-admin users. Tenant-wide admin consent has been granted and verified via Graph API. All Microsoft-documented remediations have been applied without effect. We need engineering inspection of consent state that is not visible via Graph API or PowerShell.

ENVIRONMENT

  • Tenant: xxxxxx
  • Tenant ID: xxxxxxxx
  • Azure App display name: xxxxxxxx
  • Azure App (client) ID: xxxxxxxx
  • Azure App object ID: xxxxxx
  • Walling user #1:xxxxxx
  • Walling user #2: xxxxxxxxxx
  • Working comparison user: xxxxxxxxxxx
  • Sign-in error code: 90094
  • Failure reason (verbatim): "Admin consent is required for the permissions requested by this application"
  • First observed: 2026-05-26
  • Reproducibility: 100% on both non-admin users; never on the Global Admin

PERMISSIONS REQUESTED BY APP

Delegated scopes on Office 365 Exchange Online (resource 00000002-0000-0ff1-ce00-000000000000):

  • IMAP.AccessAsUser.All (195adc35-e27b-454b-a7ed-1ecdffa1c09f)
    • SMTP.Send (76faac2a-0f20-42f1-928a-50de5b9dbe52)

Delegated scopes on Microsoft Graph:

  • offline_access
  • User.Read

TENANT-WIDE ADMIN CONSENT IS VERIFIABLY GRANTED

oauth2PermissionGrants queried via Graph API

(GET /servicePrincipals/{spId}/oauth2PermissionGrants) for the app's service principal:

{

  "value": [

scala
{

  "principalId": null,

  "resourceId": "9146ac17-59a7-4e47-8138-a790fa48793f",

  "scope": "offline_access",

  "clientId": "c7a224e0-1860-443a-abda-aa815ada9463",

  "consentType": "AllPrincipals"

},

{

  "principalId": null,

  "resourceId": "2d0b9173-b30a-4c84-afee-d9e760fb3481",

  "scope": "IMAP.AccessAsUser.All SMTP.Send",

  "clientId": "c7a224e0-1860-443a-abda-aa815ada9463",

  "consentType": "AllPrincipals"

}
 ]

}

Both grants are consentType: AllPrincipals with principalId: null — the standard

tenant-wide admin-consent shape. The Office 365 Exchange Online grant explicitly

lists both IMAP.AccessAsUser.All and SMTP.Send scopes.

WHAT WE HAVE ALREADY TRIED (17 remediations, all verified)

  1. App manifest has canonical Exchange Online UUIDs (195adc35-... IMAP + 76faac2a-... SMTP, resource 00000002-...) — confirmed in manifest
  2. Microsoft Graph manifest entries cleaned to offline_access + User.Read only — confirmed
  3. Stale Graph IMAP/SMTP entries removed from API permissions UI — UI matches manifest
  4. Admin consent granted tenant-wide via portal — "Granted for Braddock Int" on all 4 entries
  5. Admin consent re-applied via v2 endpoint URL with explicit scopes (/v2.0/adminconsent?...&scope=https://outlook.office.com/IMAP.AccessAsUser.All+...) returned admin_consent=True
  6. oauth2PermissionGrants inspected via Graph API — both grants present (see JSON above)
  7. Existing grants nuked + recreated via Graph POST — clean state, no effect on user wall
  8. Target mailboxes: licensed UserMailbox, IMAP/OWA/EWS enabled (Get-Mailbox + Get-CASMailbox clean)
  9. Get-ApplicationAccessPolicy empty for this app — no mailbox restrictions
  10. OAuth2ClientProfileEnabled: True on org config — tenant gate open
  11. EXO Service Principal registered — Get-ServicePrincipal -Identity <AppId> returns a row
  12. App "Assignment required" = No
  13. App "Allow public client flows" = Yes
  14. Tenant User consent settings reviewed (restrictive, but admin consent should override)
  15. Tested in fresh Chrome Incognito (no cached MS session) — same wall
  16. Tested with explicit account typing (no auto-fill) — same wall
  17. Multiple full Connect cycles with token resets server-side — same wall

COMPARISON: SAME APP, DIFFERENT USERS

The exact same OAuth flow (same Azure App, same scopes, same client) on

xxxxxxx(Global Admin) SUCCEEDS — token is issued, scopes are correct

(aud=https://outlook.office.com, scp=IMAP.AccessAsUser.All SMTP.Send User.Read),

SMTP works end-to-end. Both xxxxx and xxxxxxx wall at the

sign-in step with AADSTS90094. The only difference is that the working user has

the Global Admin role and the failing users do not.

(The Global Admin has a separate, unrelated downstream IMAP issue caused by

token-claim bloat from many wids entries. That is not the subject of this

ticket — sign-in itself succeeds for the admin.)

HYPOTHESES WE CANNOT VALIDATE FROM THE CUSTOMER SIDE

Microsoft Security | Microsoft Entra | Microsoft Entra ID

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-28T17:21:56.2233333+00:00

    AADSTS90094 indicates that the application is requesting permissions that only an administrator can grant, or that user consent is blocked or misaligned with the way consent was granted.

    From the provided information and the documented behavior, the most relevant points are:

    1. AADSTS90094 is expected when:
      • A non-admin user attempts to use an application that requests permissions that only an administrator can grant.
      • User consent is disabled or restricted at the tenant level.
      • The app is considered risky and user consent is blocked.
      • The app requires assignment and tenant-wide admin consent has not been correctly applied.
      This is described in the consent troubleshooting and unexpected-consent-error documentation:
      • AADSTS90094: “needs permission to access resources in your organization that only an admin can grant”.
      • AADSTS90093/90094 are raised when a non-admin user tries to use an app requesting admin-only permissions, or when risky-app policies block user consent.
    2. Tenant-wide admin consent vs. user consent and assignment:
      • Admin consent can be granted tenant-wide (consentType = AllPrincipals) so that users are not prompted for consent.
      • However, if user consent is disabled or limited, or if the app is flagged as risky, non-admin users can still be blocked and see AADSTS90094 even when admin consent exists.
      • If the app is configured to require assignment, users must be assigned and admin consent must be granted tenant-wide; otherwise, non-admin users will see consent errors.
      • The documentation explicitly notes that user consent can be blocked for risky applications and that this can surface as an admin-consent-required error.
    3. Conditions that must be true for non-admin users to sign in successfully: Based on the consent and troubleshooting articles, verify all of the following in the tenant and app configuration:
      1. User consent policy
      • In Microsoft Entra admin center, under Enterprise applications → Consent and permissions, check the user consent settings.
      • If Do not allow user consent or a restrictive policy is configured, non-admin users cannot grant any consent. In that case, the app must rely solely on admin consent and must not prompt users for consent.
      • If the app or its sign-in URL forces prompt=consent or prompt=admin_consent, non-admin users will be blocked and see AADSTS90094. Ensure the delegated user sign-in flow does not include prompt=consent or prompt=admin_consent for non-admins.
      1. Admin consent scope alignment
      • Ensure that the scopes requested in the interactive sign-in request for non-admin users exactly match the scopes that have been granted via admin consent.
      • The troubleshooting guide notes that requesting scopes that have not been consented to in a sign-in request will cause consent errors.
      • Confirm that the sign-in request for non-admin users is not including any additional scopes beyond:
        • https://outlook.office.com/IMAP.AccessAsUser.All
        • https://outlook.office.com/SMTP.Send
        • offline_access
        • User.Read
      1. Application assignment requirement
      • If the application is configured to require assignment, individual user consent is not supported; an admin must grant tenant-wide admin consent and assign users.
      • The unexpected-consent-prompt article states that for apps requiring assignment, admin must grant tenant-wide admin consent so that assigned users can sign in.
      • Confirm that either:
        • Assignment is not required, or
        • If assignment is required, the affected users are assigned to the app and tenant-wide admin consent has been granted.
      1. Risk-based consent blocking
      • The consent documentation notes that user consent can be blocked for risky applications. In that case, AADSTS90094 can appear and an audit event is logged with category ApplicationManagement, activity Consent to application, and status reason Risky application detected.
      • Check the audit logs in Microsoft Entra ID for such events related to the app. If present, an administrator must explicitly grant access and/or adjust policies that block risky apps.
      1. Service principal and baseline sign-in permissions
      • The consent troubleshooting article recommends ensuring that the app has at least User.Read or OpenId delegated permission configured and consented for user sign-in.
      • Confirm that the Graph User.Read permission is present in API permissions and has admin consent, and that the sign-in request includes the appropriate OpenID scopes as required by the platform.
    4. Engineering-level inspection
      • The documentation does not expose any additional “consent cache” or per-user consent state beyond what is visible via Graph (oauth2PermissionGrants) and the Entra admin center.
      • For persistent AADSTS90094 where:
        • Tenant-wide admin consent is confirmed (consentType = AllPrincipals),
        • Scopes requested at sign-in match the granted scopes,
        • User consent policies and assignment settings have been validated, and
        • No risky-app blocking events explain the behavior,
        the next step is to open a support ticket so that Microsoft support and engineering can inspect internal consent and policy state that is not exposed via Graph or PowerShell. This aligns with the pattern in similar high-severity tenant issues, where support escalates to internal teams for tenant-specific investigation.

    Summary of actionable checks before escalation:

    1. Remove prompt=consent / prompt=admin_consent from non-admin sign-in flows.
    2. Confirm user consent settings do not block the scenario, or rely solely on admin consent without user prompts.
    3. Ensure scopes in the sign-in request exactly match the admin-consented scopes.
    4. Verify whether the app requires assignment; if so, ensure users are assigned and admin consent is tenant-wide.
    5. Review audit logs for Risky application detected or related consent-blocking events.
    6. If all above are correct and AADSTS90094 persists only for non-admin users, open a Microsoft support ticket for tenant-level investigation.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.