Token handling in clients that don't support SSO

[ChristianGalla]

In the current documentation, there are multiple hints, that access tokens should never be cached in client code.
Unfortunately, there are many companies that are still using the still supported Office versions 2016 and 2019 without SSO support.

So, while this is a good approach in modern Office versions, not caching tokens means to show a fallback authentication prompt for each backend request in Office versions that don't support SSO. There is no user acceptance for so many prompts. Even one prompt each time an Add-In is opened is very ugly if the Add-In is heavily used (for example for each new Outlook mail).

If SSO is not back ported to Office 2016 / 2019 for commercial licenses, it should at least be allowed to cache tokens in these applications. (SSO already works in Office 2016 / 2019 when using a consumer license)

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: cb06c24b-9d11-9cc5-2e98-561601452638
• Version Independent ID: abda21d9-6e80-8319-c56f-004658014e3c
• Content: Enable single sign-on (SSO) in an Office Add-in - Office Add-ins
• Content Source: docs/develop/sso-in-office-add-ins.md
• Product: non-product-specific
• Technology: add-ins
• GitHub Login: @o365devx
• Microsoft Alias: o365devx

[AlexJerabek]

Thanks for raising this issue @ChristianGalla.

@davidchesnut, could you please help provide clarity here?

[davidchesnut]

I'm investigating if it is possible to take advantage of MSAL caching to avoid signing in the user repeatedly. Hope to have an answer soon.

[davidchesnut]

@ChristianGalla I do have this working in a PR for Excel/Word/PowerPoint. See PR 370 here. And specifically the updates to the fallbackAuthTaskpane.js file. MSAL caches the token in local, storage, or cookie storage. You configure that when setting up the config parameters.

I have not yet tested this with Outlook. That will take some more time. But if the local storage or session storage is persisted between add-in activations (such as each time a compose mail item is opened) this seems like it should work. No guarantees, but I'll update here once I have more info.