Outlook-Add-in-SSO-NAA double popups Firefox/Safari #889
Comments
|
Thanks for flagging this @malnoxon. @codexeon or @davidchesnut, could you please take a look? |
AlexJerabek
added
area: authentication
Needs: attention 👋
and removed
needs triage 🔍
labels
|
I am able to reproduce this behavior so I'm looking into this. |
davidchesnut
added
bug: product
Status: under investigation
and removed
Needs: attention 👋
labels
|
Tracking as bug: 325416. |
|
@malnoxon @davidchesnut |
|
I believe this is expected. Silent token acquisition cannot be performed in all cases. Your console logs show the following error:
which is an expected MSAL error ( If popups are blocked, your app/addin should have UI to handle the resulting MSAL error (typically For Firefox, there's a setting that's defaulted to off that enables integration with Windows SSO which should allow silent SSO to happen: https://support.mozilla.org/en-US/kb/windows-sso For Safari, I believe there are some platform broker SSO extensions that Intune installs to help this flow, but I haven't personally tested if it allows MSAL SSO to succeed in this case. |
|
Thank you very much @salaman . I understand and take your points well and appreciate them. The way I see this is that, NAA-SSO is the future replacement of getCallbackTokenAsync. And in a way, addin users expect NAA-SSO would be as seamless as getCallbackTokenAsync. I guess what I am trying to drive at is that addin end users are so used to the 'silent' and seamless execution of getCallbackTokenAsync, that having popups for login will most likely result to unfavorable user experience. Most users would be surprised with two login popup windows that automatically close. I was just hoping that whether it is via silent token acquisition (or via interactive acquisition), these NAA-SSO calls would be as good as the current getCallbackTokenAsync. Thanks for this link : https://support.mozilla.org/en-US/kb/windows-sso. Unfortunately though, this won't work for MAC running firefox. As for our addin, we intend to fallback to SSO-OBO if silent-token-acquisition for NAA-SSO fails. And if SSO-OBO fails, we will fall back to REST or EWS. It would really be great if the NAA-SSO flow can equal the convenience/seamlessness of getCallbackTokenAsync. I hope I make sense. Thanks. |
|
I agree; however, without a fully managed device and browser capable of platform-based single sign on, there is always the possibility of prompting due to the nature of iframes and browser security restrictions. I'll look into the two popup issue and try to improve the flow to simplify it to one popup. Separately, Outlook Web is in process of rolling out major improvements to its auth stack, at which point NAA should be even more reliable and some of this prompting will be done in a more 'global' way during initial Outlook load. I don't have a firm date for these changes to fully roll out, but I expect them to be gradually rolling out through this current quarter. I can tell you that the behaviour is a lot better in Firefox with the changes :) |
|
Noting that the double popup window can be avoided by:
Not particularly viable to tell our end users to do this unfortunately |
|
I've merged a change internally that should hopefully reduce this flow down to one popup instead of two, and improve the fetch performance overall. You should see it deployed by the end of next week. The popup itself is unavoidable for now; however as I mentioned earlier, Outlook is actively rolling out changes to the auth stack that should meaningfully reduce the occurrence of these popups down to only when strictly necessary (consent required, conditional access policies, MFA, etc), but those are still a work in progress and are planned for the end of Q1. |
URL of sample
https://github.com/OfficeDev/Office-Add-in-samples/tree/main/Samples/auth/Outlook-Add-in-SSO-NAA
Describe the bug
I routinely get double popups the first time I try to click the "Get user data" button in Firefox or Safari on a fresh login or private window due to a failure to silently get a token in those cases. They open and then automatically close with no user intervention. I do not get these popups in chrome under the same conditions where silent token retrieval is successful.
This is both a UX annoyance and can cause functional issues if the browser is configured to block popups. The particular scenario I'm concerned about is if an admin grants consent on behalf of the org in which case the end users should see 0 popups prompting them for consent and ideally never need to allow popups.
This may be a combination of 2 issues:
To Reproduce
Sideload in the add-in
Expected behavior
After permissions have been granted I'd expect no popups to be necessesary like in chrome.
Screenshots
Firefox console logs
Chrome logs when performing the same action
Environment
Additional context
n/a
The text was updated successfully, but these errors were encountered: