Outlook NAA: Migration path in code

[manuelsidler]

Based on the latest blog post about deprecating legacy Exchange Online tokens (https://devblogs.microsoft.com/microsoft365dev/updates-on-deprecating-legacy-exchange-online-tokens-for-outlook-add-ins/) we'll have three scenarios to support in our Outlook add-in:

• On-prem users
• M365 users with NAA support
• M365 users without NAA support

• Is my assumption of the scenarios and the flow correct?
• How can we check NAA support by code?
• What happens in event-based add-ins for M365 users, for which legacy tokens are deprecated but don't have NAA support yet?

Edit: While fiddling around with NAA today, I found some answers (and more questions):

• There already seems to be a requirement set, which we can check for NAA support: Office.context.requirements.isSetSupported('NestedAppAuth', '1.1'). Is that the recommended way?
• createNestablePublicClientApplication has a fallback based on the doc: creates NestedAppAuthController and passes it to the PublicClientApplication, falls back to StandardController if NestedAppAuthController is not available. So no need to fallback explicitly when NAA is not supported?
• acquireTokenPopup seems to work on hosts without NAA support (tested with new Outlook on Windows and classic Outlook [Current Channel]). Is a fallback to the login dialog still needed as stated in the NAA documentation?

[davidchesnut]

Hi @manuelsidler that flowchart is great! We're working on a sample that will show how to handle fallback scenarios, and can update this issue once it is ready in PR. The scenarios you point out are exactly what we are looking to show how to do. Thanks!

[manuelsidler]

@davidchesnut is there any timeline for when we can expect a sample to handle legacy scenarios?