Sample: Outlook-Add-in-SSO-NAA

[GrumpyAL]

Question

Should the acquireTokenSilent() part of this sample work? I am trying to evaluate potential user experience changes for our add-in and determine when a login may be required. However, with this sample (as well as a test I built) I am always getting the login-prompt. Every time I press the button it will prompt for the login again (not just the first time where consent is needed). Is this a bug or am I doing something wrong?

Outlook is on beta channel and 17531

App Registration:

Thanks!

[samantharamon]

Thanks for reaching out, @GrumpyAL.

@davidchesnut, could you please investigate this?

[davidchesnut]

Hi @GrumpyAL,

Thanks for letting us know. The sample should work and once you have consented through the dialog, acquireTokenSilent should work. Can you let us know what error acquireTokenSilent is returning? Also when you are prompted to sign in again, does the sign in work and are you able to retrieve file names from OneDrive?

Thanks!
David

[GrumpyAL]

@davidchesnut,

Thanks for the response. I should have read that console error message closer. I see now that it was failing to acquire silently because my primary SMTP that it's pulling from Office.context.mailbox.userProfile.emailAddress doesn't match my UPN. I changed my primary SMTP back to my UPN and it's working as expected. A couple of follow-up questions:

1. Is there a work around for this? I suspect this will be an issue for some users that have gone through a domain name change at some point. If there's nothing built in, I'm sure we can come up with some code to account for this scenario to avoid the login prompt every use.

2. I noticed that when I register the app as AzureADandPersonalMicrosoftAccount as instructed, when I get the login prompt I Have to do a full login (supply username and password). However, when I register it as AzureADMultipleOrgs I only have to select the account I want to use. I don't think there are any other differences in the registration but I did notice this difference in the manifest. In the AzureADandPersonalMicrosoftAccount manifest there is this "accessTokenAcceptedVersion": 2,but in the AzureADMultipleOrgs manifest it is "accessTokenAcceptedVersion": null, Both registrations otherwise work the same as far as I can tell. Is it alright to use AzureADMultipleOrgs if we don't need to target personal account users?

3. I notice the sample says it works on Outlook on Windows, Outlook on Mac and Outlook on the Web. Will this functionality come to Outlook on iOS/Android as well?

Thank you!

[mattgeim]

@davidchesnut,

Thanks for the response. I should have read that console error message closer. I see now that it was failing to acquire silently because my primary SMTP that it's pulling from Office.context.mailbox.userProfile.emailAddress doesn't match my UPN. I changed my primary SMTP back to my UPN and it's working as expected. A couple of follow-up questions:

1. Is there a work around for this? I suspect this will be an issue for some users that have gone through a domain name change at some point. If there's nothing built in, I'm sure we can come up with some code to account for this scenario to avoid the login prompt every use.

We will have a mechanism for getting the UPN from office.js - stay tuned for an update soon on this.

3. I notice the sample says it works on Outlook on Windows, Outlook on Mac and Outlook on the Web. Will this functionality come to Outlook on iOS/Android as well?

Yes, we will have mobile support as well for Outlook on iOS and Android. Android may be testable now as preview, although we are still finalizing the rollout. Outlook on iOS is in progress, but not testable for preview functionality at this time. We will be updating the community when both Outlook on iOS and Android are available.

For question 2 - we will follow up on this one shortly - thanks for the questions and trying the NAA functionality, @GrumpyAL !

[GrumpyAL]

@mattgeim,

Thanks so much for the response. While tinkering with the sample I came up with one more question (I hope this is the appropriate place to ask).

Is it intended that this will work on Trident to support the Outlook clients that don't use edge? (Ref). I'd be most concerned about 2019/2016 volume licensed from that list. I tried to get it to run with babel/webpack but had no luck. Just wondering what the plan is for supporting those webviews or do we just need to plan on a fallback like office dialog there? (Edit: Found this msal-browser doc, so it looks like v3 (which is needed for NAA?) will not support IE11).

Additionally, I basically use ES5 right now to ensure support of IE11 webviews, so new async/await etc. Assuming I'll have to finally bump up to ES6 to get the NAA code imported/implemented? I can't seem to find a way to load it with ES5/require and saw the CDN version stopped at 2.

Thanks again, appreciate all of your assistance.

[davidchesnut]

Hi @GrumpyAL, I don't believe you'll be able to run NAA on older Office clients using IE webview. @mattgeim please correct me if I'm wrong.

Good question on using ES5 vs ES6 and NAA compatibility. NAA is implemented in the MSAL js browser library. I recommend reaching out to the identity folks for help on that question. See the community support and help options. I know sometimes you can use a polyfill such as on 2.x, but I don't know for the latest library version.

Hope this helps!
David

[Nurou]

Could anyone please provide clarity/confirmation on this?

I don't believe you'll be able to run NAA on older Office clients using IE webview

It's an important question as IE is still used by Outlook 2016 and 2019 volume licenses cc: @mattgeim @davidchesnut

[mattgeim]

Could anyone please provide clarity/confirmation on this?

I don't believe you'll be able to run NAA on older Office clients using IE webview

It's an important question as IE is still used by Outlook 2016 and 2019 volume licenses cc: @mattgeim @davidchesnut

NAA won't be supported in add-ins using Trident+/IE - The minimum version required of MSAL.js to perform NAA flows does not support Internet Explorer/Internet Explorer-based webviews.

[akrantz]

@mattgeim @davidchesnut It would be good to clarify the requirements here for add-in developers.

If there a way to signify in the manifest so add-ins which only want to be available on Office versions which support NAA / modern webview/browser, how do they do that? Is there a requirement set which should be used to signify this?

If the add-in wants to be able to run regardless, but have a runtime check so NAA is only used when available, and there is a fallback or error when it isn't available, how would they do that?