Canva OneDrive integration still returns AADSTS90094 after admin consent granted in Entra ID

AADSTS90094 indicates that the app is requesting permissions that require admin consent and that the current user is not allowed to grant them. In Entra ID this is driven by:

• Which scopes the app is actually requesting at sign-in
• Tenant-wide user-consent settings
• Whether the app is considered risky or has admin-restricted permissions
• Whether admin consent has been granted for all requested scopes

Based on the context, the next steps focus on verifying what Canva is requesting and then ensuring admin consent is applied at the right place.

1. Where tenant-wide admin consent must be granted

For a third‑party multitenant SaaS app like “Canva OneDrive” that appears only under Enterprise applications:

1. In Microsoft Entra admin center, go to Entra ID → Enterprise applications → All applications → Canva OneDrive.
2. Under Security, open Permissions (or Permissions / API permissions depending on UI).
3. Use Grant admin consent from this pane to perform tenant‑wide admin consent for all listed permissions.
4. When the consent dialog appears, expand the permissions list and compare it with the table on the Permissions page. Any permission shown in the dialog but not in the table has not yet been consented and can cause repeated AADSTS90094 prompts.

This is the correct location to grant tenant‑wide admin consent for a third‑party Enterprise application; there is no separate “hidden” location beyond:

• Enterprise app → Permissions / Grant admin consent
• Or the admin consent endpoint flow described in Using the admin consent endpoint (referenced in the context).

Also verify:

• User assignment required? is set to No (already done).
• A service principal for the Canva client app exists in the tenant (the Enterprise app entry itself is that service principal).

2. Why users still see AADSTS90094 after admin consent

From the consent troubleshooting guidance:

• AADSTS90094 is raised when a non‑admin user attempts to use an app that is requesting permissions that only an admin can grant, or when user consent is blocked for risky apps.
• It can also occur if user assignment is required and tenant‑wide admin consent has not been granted.

Key checks:

1. Confirm all requested scopes are consented
   • Capture the actual sign‑in request when the Canva consent screen appears (for example, from the browser address bar or via Fiddler), as described in the “Get the sign-in request” step:
     • For v2 endpoint: .../oauth2/v2.0/authorize?...&scope=<Scope>&prompt=<Prompt>
   • Inspect the scope parameter (for example: openid User.Read Files.ReadWrite.All Sites.Read.All ...).
   • Ensure every scope listed there appears on the Enterprise app’s Permissions page and has Admin consent granted.
   • If Canva dynamically requests additional scopes beyond the static list, those will continue to trigger consent until an admin grants them.
2. Check tenant user-consent settings and risky-app blocking
   • In Entra admin center → Enterprise applications → Consent and permissions, verify:
     • User consent is not globally disabled if Canva expects users to grant consent themselves.
     • If user consent is allowed only for low‑impact permissions, but Canva requests admin‑restricted scopes (for example, broad Files.ReadWrite.All or Sites.ReadWrite.All), then only admin consent will work.
   • In the Audit logs, look for Activity = Consent to application and review Status reason. If it shows something like Risky application detected or UserConsentBlockedForRiskyAppsException, then user consent is blocked for this app and admin consent is mandatory.
3. Why some permissions still show under “User consent”

The Permissions page distinguishes between:

• Permissions granted by individual users (“User consent”)
• Permissions granted by an admin on behalf of the organization (“Admin consent”)

If some scopes remain under “User consent” after using Grant admin consent, it usually means:

• Those scopes were granted only by individual users in the past, and
• The current admin consent operation did not include them (for example, they are not part of the static permission set or are being requested dynamically only at runtime).

The fix is to:

• Trigger the Canva sign‑in/consent flow as a Global Admin, so the consent prompt shows all currently requested scopes.
• In that prompt, grant consent “on behalf of the organization”.
• Confirm afterwards that those scopes now appear under Admin consent for the Enterprise app.

3. Stale delegated consent or service principal state

From the consent troubleshooting article:

• A missing or misconfigured service principal, or scopes that haven’t been consented, can cause repeated consent prompts and errors.
• Also, if a consent URL is explicitly using prompt=admin_consent or prompt=consent, it will force a consent flow.

To rule out stale state:

1. Verify that the Canva OneDrive service principal (Enterprise app) has the expected Object ID and is not duplicated.
2. Ensure the app has at least a basic sign‑in permission such as User.Read or Openid configured and consented.
3. Check sign‑in logs for the failing event and confirm:
   • Authentication is successful.
   • Conditional Access is success (already confirmed).
   • The failure is specifically at Consent with AADSTS90094.

If everything above is correct and the app still fails, stale consent/service principal state is possible but not the most common cause; the more frequent root cause is missing admin consent for one or more scopes or risky‑app blocking.

4. Whether deleting/recreating the Enterprise Application is recommended

The documentation does not prescribe deletion/recreation as a standard fix for AADSTS90094. The recommended approach is:

1. Identify the exact scopes requested in the sign‑in request.
2. Ensure tenant settings allow the required type of consent.
3. Perform admin consent for all requested scopes via the Enterprise app’s Permissions → Grant admin consent flow or the admin consent endpoint.
4. Check audit logs for risky‑app blocking and, if present, handle according to organizational policy.

Deleting and re‑adding the Enterprise app could clear stale user‑consent entries, but it is a last resort after confirming the above. It is not required by the platform to resolve AADSTS90094.

Summary of concrete steps for this scenario

1. Capture the Canva authorization URL and list the scopes in scope=.
2. In Entra admin center → Enterprise applications → Canva OneDrive → Permissions, verify every scope from step 1 is present and has Admin consent granted.
3. As a Global Admin, run the Canva sign‑in again, and when the consent prompt appears, grant consent on behalf of the organization. Compare the prompt’s permission list with the Permissions page.
4. In Enterprise applications → Consent and permissions, confirm user consent settings and check for any risky‑app blocking.
5. In Audit logs, filter by Activity = Consent to application for Canva and review Status reason for hints like “Risky application detected” or “UserConsentBlockedForRiskyAppsException.”

If, after these steps, AADSTS90094 persists and all scopes are clearly admin‑consented, opening a support case with Microsoft (and optionally Canva) is appropriate, referencing the consent troubleshooting and unexpected‑consent‑error guidance.

References:

• Unexpected error when performing consent to an application
• Troubleshoot consent issues in Microsoft Entra ID
• Unexpected consent prompt when signing in to an application
• Consent experience for applications in Microsoft Entra ID
• Problems signing in to a Microsoft application
• Corporate account apps registration error: AADSTS90094 - Microsoft Q&A