Outlook Add-in: Token Cache Not Reused in NAA Scenario, Leading to Performance Degradation #5237
Comments
|
Here are some similar issues that might help you. Please check if they can solve your problem.
Possible solution (Extracted from existing issue, might be incorrect; please verify carefully) Solution 1:There is a new NAA sample in PR that shows how to implement NAA in events. In particular, you have to be careful how to configure webpack to avoid pulling in hot reload code when importing MSAL JS. This might help with the issues you are seeing. Reference: Solution 2:Acquiring an access token via NAA in send event now works with beta channel version 16.0.18028.20004. Reference: Solution 3:The sample is now published at https://github.com/OfficeDev/Office-Add-in-samples/tree/main/Samples/auth/Outlook-Event-SSO-NAA. This might provide guidance on implementing NAA correctly. Reference: |
microsoft-github-policy-service
bot
added
the
Needs: triage 🔍
exextoc
added
Needs: attention 👋
|
Hi @MortenGuldbaek, I'm not able to reproduce this behavior. Can you share which scopes you are requesting? Also do you see the same behavior in other browsers? if not, could be there is a setting in Chrome throwing it off and we could try to track down what it is. Thanks, |
davidchesnut
added
Area: authentication
microsoft-github-policy-service
bot
added
the
Status: no recent activity
|
Hi David, thanks for responding I just tried re-running the Add-in from Microsoft Edge, and I experience the same behavior here. The scopes we are requesting in the silent request are the following: SharePoint REST call Graph REST call Looking over the AzureAD/microsoft-authentication-library-for-js issue list, it seems there are several related issues where token cache is not being used, so it might be related. |
microsoft-github-policy-service
bot
added
Needs: attention 👋
|
Hi @MortenGuldbaek, What scopes are covered by the graph.microsoft.com/.default scope? Are you requesting anything other than openid, profile, and offline_access? It's required to have at least one resource scope to get a valid access token. More info. Even though this will work on some platform scenarios, just wondering if that has anything to do with the behavior. Thanks, |
|
Hi @davidchesnut we have several scopes scopes other than the ones you mention. The same goes for our other resources, fx. for SharePoint REST. We do also get a valid token in all scenarios, it just won't reuse the token cache it creates in localStorage. |
|
I'm encountering the same issue with an Outlook add-in with NAA not using cached tokens but issuing a token request for every web request the add-in makes. This can be reproduced by running the below sample add-in in OWA (add your client ID in The repro add-in is the Outlook NAA sample add-in with session storage enabled: Note: I tested with the latest "@azure/msal-browser" 4.0.1 in OWA in Chrome. The issue does not occur when using Outlook Desktop (new or legacy). 
|
When using NAA, the Outlook Add-in is never able to reuse the token cache, due to the BridgeProxy.initializeNestedAppAuthBridge response not containing an accountContext.
Expected Behavior
A user should be able to open and use our Outlook Add-in in their browser or the new Outlook App. They should be able to browse views utilizing Microsoft Graph data by getting a token and using Single Sign-On with MSAL in an NAA scenario without repeated token requests.
Current Behavior
Although the functionality is correct, the actual experience is slow, as every Graph API request triggers a new token request instead of reusing the previously fetched tokens. The same goes for other resources, fx. SharePoint REST.
The bearer tokens previously fetched, and visible in the browser localStorage, should be reused, as to improve performance.
Steps to Reproduce, or Live Example
acquireTokenSilentmethod to fetch a token right before making each request.Context
The performance is slow due to token requests being executed before each data load.
My investigation found that the 'BridgeProxy.initializeNestedAppAuthBridge' response never actually returns an account that can be used for the caching:
@azure/msal-browser/src/naa/BridgeProxy.ts
The response should contain "accountContext" and "capabilities" but they do not exist.
This is the only place in the entire library that the account context that is used for looking up the token cache is set.
This in turn ensures that the currentAccount is never set:
@azure/msal-browser/src/controllers/NestedAppAuthController.ts
As a result, all requests work correctly but make redundant calls to the token endpoint.
Your Environment
Useful logs
Here is an example, but with SharePoint REST (different resource and scopes) from the same app:
And the corresponding log:
The text was updated successfully, but these errors were encountered: