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 👋
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: