Access Denied Error (3399614466) When Acquiring NAA Token in Outlook Add-in

Question

Issue Description:

---

We are imlementing sso in Outlook Add-in using Nested App Authentication (NAA) with

MSAL.js (createNestablePublicClientApplication). When calling acquireTokenPopup().

I have taken all references from here https://learn.microsoft.com/en-us/office/dev/add-ins/develop/enable-nested-app-authentication-in-your-add-in?tabs=outlook#initialize-the-msal-library-1

The solution is working fine for the Outlook web application, but not working in the Outlook desktop application.

we receive an "Access denied for the resource" error.

Error Details:

• Correlation Id: [Moderator note: personal info removed]
• Timestamp: 2026-04-06T13:30:07.000Z
• DPTI: [Moderator note: personal info removed]
• Message: Access denied for the resource.
• Tag: 7q6cl
• Code: 3399614466

Scope Requested:

---

['openid', 'profile', 'api://{clientId}/access_as_user']

Environment:

---

• Platform: Outlook Desktop - Version 2603 Build 16.0.19822.20086) 64-bit
• MSAL Version: (4.10.0)

Steps Already Taken:

---

1. Verified 'access_as_user' scope is defined in "Expose an API"
2. Verified Application ID URI matches api://{clientId}
3. Checked authorized client applications for Office clients
4. Confirmed API permissions and admin consent

Questions:

---

1. Why is access being denied despite correct configuration?
2. Are there additional pre-authorized applications needed for NAA?

Answer 1

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi @Nobilex

Please note that there is an official forum to raise issue that is related NAA on GitHub. You can also ask your question via OfficeDev/office-js GitHub issues site.

However, I will try my best to provide you as much information as I got.

From this article, Nested app authentication FAQ - Office Add-ins | Microsoft Learn, you can check if the admin has any conditional access policies applied that enforce specific client restrictions, such as mobile location, or platform type. Also, the approved client app Conditional Access grant is deprecated and will cause these errors with NAA token requests. An admin must completely remove this policy and switch over to the newer application protection policy grant for NAA to work.

About pre-authentication, I found that you need preauthorize your client application to call itself. I saw that you already did this. Can you double check if you did this like the step below?

1. In your app registration, go to Manage > Expose an API.
2. In the same Expose an API pane, select Add a client application.
3. Enter the client ID of your app registration (the same one you are in) which is found on the Overview page
4. Select the access_as_user scope and then select Add application.

See the readme for more details.

For you to receive the best suggestion and guidance about your concern with NAA, I recommend posting your scenario in the OfficeDev/office-js GitHub issues site. This forum is actively monitored by experienced users, and engineers who can provide detailed guidance and share best practices.    

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Access is being denied because the Outlook desktop client is enforcing tenant security and Conditional Access requirements that block the NAA/MSAL token request, even though the app registration and scopes are configured correctly.

From the provided context, several NAA-related behaviors are relevant:

1. Conditional Access policies can block NAA
   • NAA token requests are sensitive to Conditional Access (CA) policies, especially device and client restrictions. The documentation notes that:
     • The approved client app Conditional Access grant is deprecated and not supported by MSAL NAA. If this grant is still configured, NAA token requests fail, even if the add-in is granted an exception.
     • Other CA policies (for example, device management or platform restrictions) can also block add-ins using NAA.
   • This explains why Outlook on the web can work while Outlook desktop fails: the desktop client may be subject to different CA conditions (e.g., device compliance, app protection policy, or legacy “approved client app” grant) that are not applied to the browser session.
2. NAA requires moving from legacy “approved client app” to app protection policies
   • The NAA FAQ explicitly states that the approved client app Conditional Access grant must be removed and replaced with the newer application protection policy grant for NAA to work.
   • If the tenant still uses the deprecated grant, NAA calls from Outlook desktop will return errors from Conditional Access, which surface as generic “Access denied for the resource”/“Something went wrong” messages.
3. Other Conditional Access/device management policies can cause similar errors
   • Policies that enforce specific client types, locations, or device management states can block the Outlook desktop client while allowing browser access.
   • The documentation recommends reviewing device management types and app protection policies when NAA calls fail.

Answers to the specific questions

1. Why is access being denied despite correct configuration?
   • The app registration and scopes can be correct, yet NAA token acquisition fails because Conditional Access or device management policies in the tenant block the Outlook desktop client. In particular, if the tenant still uses the deprecated approved client app grant, MSAL NAA is not supported and returns errors for NAA token requests.
   Recommended checks for the tenant admin:
   • Review Conditional Access policies targeting Office/Outlook and the user:
     • Remove any use of the approved client app grant and migrate to application protection policy–based grants.
     • Check for device-compliance or platform restrictions that might block the desktop client but not the browser.
   • After policy changes, retry the NAA flow in Outlook desktop.
2. Are there additional pre-authorized applications needed for NAA?
   • The context does not list any extra pre-authorized client IDs beyond the standard NAA guidance. Instead, it emphasizes that NAA relies on MSAL.js and that issues are typically due to Conditional Access or device management policies, not missing pre-authorizations.
   • Ensure that NAA is supported in the host and that the add-in has a fallback when NAA is not supported, using Office.context.requirements.isSetSupported("NestedAppAuth", "1.1") as shown in the best practices.

In summary, the error is most likely caused by Conditional Access or device management policies (especially the deprecated approved client app grant) blocking NAA token requests from Outlook desktop. The tenant admin should remove the deprecated grant, migrate to application protection policy–based grants, and review any device/platform restrictions affecting the desktop client.

---

References:

• Nested app authentication FAQ
• Enable single sign-on in an Office Add-in with nested app authentication
• Authentication options in Outlook add-ins
• Outlook add-in API requirement set 1.1