Error acquiring token via NAA when clientCapabilities configuration provided

[LiamWarnes]

Core Library

MSAL.js (@azure/msal-browser)

Core Library Version

3.27.0

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

None

Public or Confidential Client?

Public

Description

I have recently been working on an issue with supporting conditional access policies in our Outlook add-in and run into some problems with supporting location-based access policies when backend microservices are hosted in different geolocations. Consequently, we made moves to explicitly not support conditional access policies until we understand better how to resolve this (ongoing with other Microsoft contacts). We have identified use of the clientCapabilities option on the msal config as a means to support conditional access policies or not.

I have encountered an error specific to PC Outlook desktop client when attempting to acquire a token with NAA, which differs from behaviors that may be associated with Outlook on the Web.

When clientCapabilites option is supplied with an empty array [""], error is happening in Outlook PC only.

Outlook on the Web seems to overcome this, however from the token that is generated in that context, it does not seem to respect any value supplied in this configuration anyway (e.g. omitting a clientCapabilities option will still return xms_cc claim and i dont believe it should) - just mentioning this because OWA may not be working as it should be expected to.

You can try out supplying msal config in these 3 formats and compare the resulting token using jwt.ms to see differences in behavior for the two Outlook platforms - second option produces the error

auth: {
clientId: 'clientId',
clientCapabilities: ["cp1"]
}

auth: {
clientId: 'clientId',
clientCapabilities: [""]
}

auth: {
clientId: 'clientId',
}

Error Message

ServerError
at NestedAppAuthAdapter.fromBridgeError (NestedAppAuthAdapter.mjs:140:28)
at _NestedAppAuthController. (NestedAppAuthController.mjs:163:53)
at Generator.throw ()
at rejected (chunk-47AXDMZD.js?v=ec7d723b:50:29)
at _ZoneDelegate.invoke (zone.js:365:28)
at Object.onInvoke (core.mjs:14882:33)
at _ZoneDelegate.invoke (zone.js:364:34)
at _ZoneImpl.run (zone.js:111:43)
at zone.js:2498:40
at _ZoneDelegate.invokeTask (zone.js:398:33)

MSAL Logs

No response

Network Trace (Preferrably Fiddler)

• Sent
• Pending

MSAL Configuration

{
cache: {
    cacheLocation: 'localStorage'
},
auth: {
    clientId: 'clientId',

    // Comment out the following line to successfully acquire a token via NAA
    clientCapabilities: [""]
}
}

Relevant Code Snippets

https://github.com/LiamWarnes/outlook-app/tree/NAA-bridgeError

Reproduction Steps

1. Clone the repo at https://github.com/LiamWarnes/outlook-app/tree/NAA-bridgeError

2. Sideload the add-in manifest contained within the repo via https://aka.ms/olksideload -> My add-ins -> Custom Addins -> Add a custom add-in:
   

3. For your convenience, the addin is setup to use an existing multi-tenant app registration that should induce the error. However you if you are required to setup your own app registration - please follow instructions at https://learn.microsoft.com/en-us/office/dev/add-ins/develop/enable-nested-app-authentication-in-your-add-in

4. Serve the repo using npm run start

5. Open Outlook for PC desktop client, version info:
   

6. Select an email and launch the addin, then click the login button
   

7. Dev tools console is set up to display the error:
   

Expected Behavior

Don't know?

if an empty array [""] is not an expected value for the clientCapabilites msal config option, then i would prefer it failed at an earlier stage (e.g. init of public client) with a more meaningful method.

if OWA acquisition of token is working and Outlook PC is not - i dont know which one is behaving correctly? why are these different?

Identity Provider

Entra ID (formerly Azure AD) / MSA

Browsers Affected (Select all that apply)

Edge

Regression

No response