Microsoft-authentication-library-for-js: Outlook add-in - MSAL authentication

[hhertogh]

Hey,

I'm trying to use MSAL.JS in an Outlook add-in (with the new MSAL 1.2.0 version).
When using the loginPopup method in Outlook online, there is no issue , everything works as expected, but when doing the same in the Outlook client, the popup does not open, we have to choose an application from Microsoft Store to open the "about" page (the popup I suppose):

When trying to use the loginRedirect method, in Outlook client, a browser window gets opened and then redirects to my redirect page, but then I don't know how to proceed as I have a page opened in my browser and the iframe in Outlook, in your release notes I saw the following:

acquireTokenRedirect(), loginRedirect():

_In order to prevent clickjacking, any interaction is blocked in an iframe by the Microsoft Identity. Hence if you try to call acquireTokenRedirect()/loginRedirect() in an app embedded in an iframe, it wouldn't work.
To solve this scenario and provide support for certain app architectures to use these APIs, we have architected a solution which allows the top-framed application to implement the redirect flow on behalf of the embedded (in an iframe) application._

Could you please give documentation example on how we are supposed to achieve this authentication flow with MSAL.JS in an outlook add-in on a desktop client?

Thanks a lot,

PS: I've tried this on Outlook on Windows and Mac. Same results.

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x ] Documentation issue or request
[ ] Other... Please describe:

Library version

Library version: 1.2.0

[sameerag]

@hhertogh I believe Office plugin in native apps use MSAL C++: https://github.com/AzureAD/microsoft-authentication-library-for-cpp for authentication. We are working on a JS solution for native environments as there are other considerations for SSO in native environments other then browser scenarios.

Having said that the redirect solution is supported now in the beta for iframed applications, the code is already in the beta versions. We have been focused on fixing the bugs in the beta versions last week and will update the sample and documentation for redirect use cases this week.

I will update this thread soon once it is available.

[hhertogh]

Thanks sameerag for your answer. I was not following the SSO path for my authentication, but I was considering this scenario: https://docs.microsoft.com/en-us/office/dev/add-ins/develop/authorize-to-microsoft-graph-without-sso

So should I understand that it's not possible to use MSAL.JS for authentication in an native environments (Outlook client application on Windows) ? Or it will be possible with the redirect flow ?

Thanks!

[sameerag]

CC @negoe.
Native apps support for SSO is being pursued with msal c++ as far as I know. Please email us and we can direct you to the PM who is tracking this effort.

[hhertogh]

It's not a SSO case here (as explained above). So MSAL.JS cannot be used in native apps (outlook client) ? The link to the msal cpp library is not working (above)

[eirikb]

I am able to login using loginRedirect + acquireTokenSilent with 1.2.0-beta.3.
I am not 100% sure how safe this is - as in will it always work, or will the clickjacking prevention kick in for other customers etc.

I am _not_ able to use loginPopup, if I try I get the same error as @hhertogh . I would expect this to be the correct approach, because of iframe in an iframe. If @sameerag can confirm redirect will always work in all circumstances then I will use redirect.

[hhertogh]

@eirikb : can you explain how you did your loginRedirect implementation ? Maybe some code to share ?

[eirikb]

@hhertogh Here is a small example:
https://gist.github.com/eirikb/69f35c322347842ea05f6b0409ad526a
Note: I use ngrok in order to load the add-in with https in Outlook native.

[eirikb]

@hhertogh Note, turns out this only works when I have

<AppDomain>https://login.microsoftonline.com</AppDomain>`

This probably makes sense, but it also seems strange to have to do - I'm a bit skeptical to this approach. Feedback from Microsoft would be great.

[hhertogh]

@eirikb : thanks for the example!
Is this working as well on Outlook web ? What I find weird in your example, is that your are not specifying any redirecturl... is this done on purpose ?

[eirikb]

No it does not work on web, not in IE11 either, but on web loginWithPopup works, so my plan is to somehow detect Outlook native and use redirect only there, and for the rest show a login button.
Unless Microsoft has a better suggestion.

I don't use redirecturl because I don't need it, when not used it would default to the current url which is always correct for me.
When developing locally that would be either localhost, or ngrok in this case, and when in production some Azure CDN (with or without custom domain, doesn't matter).
Perhaps it is bad practice to link to external scripts, as it should be, and other extension providers block this now (e.g., Chrome extensions), but it still works here. Makes my life easier - unless it has downsides I don't know about?

[hhertogh]

@eirikb : which version of Windows / outlook are you working on ?
I am not able to do the loginRedirect either. The loginRedirect opens a new tab in my browser and I've the following error: AADSTS900561: The endpoint only accepts POST requests. Received a GET request...

[eirikb]

@hhertogh Version 1908, build 11929.20396, Windows 10 Enterprise. I only use it for testing.
Did you add the AppDomain? Note if you added this after installing I think you need to bump the version number before re-adding it. I have only tested on one single computer, probably should test on more but I'm currently out of office.

[eirikb]

@hhertogh Just had a coworker test my Demo, he got the same result as you. So my solution does not work.
@sameerag help! 😄

[hhertogh]

Yes, I've this since I updated my laptop to the latest available update (Windows 10 pro, version 1903, build: 18362.76) I'm suspecting an Edge issue ...

[eirikb]

Is this issue related to #899 ?
If this is a pure Outlook problem then it's not, and since msal beta (seemingly) works in Outlook web I'm inclined to believe it is a problem with Outlook.

[eirikb]

@hhertogh I think I might have found a workaround, try this: https://github.com/eirikb/msal-outlook-demo

[hhertogh]

Interesting ... are you able to make it work with last version of msal ?
https://alcdn.msauth.net/lib/1.2.0/js/msal.js
I'm not ...

• what is the redirect uri specified in your app registration on azure ? have you checked any other settings ?

[eirikb]

Using the version in package.json-file; 1.2.0.
Tested on my computer and two different VMs (but with my account).
Latest test now using this version of Outlook: "Microsoft Outlook for Office 365 MSO (16.0.11929.20436) 32-bit".
Redirect URI has https://someuser.ngrok.io and https://someuser.ngrok.io/index.html .
Had one coworker test it, and it didn't work for him, but I'm not quite sure why. The popup opened, but only showed "Login...".

Did you try Outlook Web? It should work there as well - for my coworker it did work on Web.
Also, did you get an error message - how far did you get?

[eirikb]

Another coworker tested, and my solution worked for him. If it does not work for others that might be because of some corner-cases not being handled by me, but the theory is still good.
Try Outlook Web first, and then Native.

My solution is to replace openPopup of MSAL with custom hack using Outlook Office API Dialog.
I had a look at Office-js-helpers to see how they managed to do the login, and saw they used the Office dialog. They don't (yet) use MSAL.

@jmckennon @sameerag any comments? If using the Office dialog is required I don't think it should be solved by MSAL directly, but perhaps Office-js-helpers should start using MSAL for Microsoft auth? - in either case, some way to replace popup flow is required. Office dialog does not support opening "about:blank" and then redirect (probably done to prevent popup block), which MSAL now does, so I had to hack around that.

[hhertogh]

Indeed, I could successfully reproduce it as well using your custom hack. Thanks!
I don't put the parameter "{ displayInIframe: true }" otherwise I had some errors on Outlook web about CORS issues, don't really know why ...
But sometimes, for some reason, authentication does not complete or stays in a "in progress" status. Sometimes the login popup does not close after authentication ... weird as well ..
Have you done more tests ? You have some updates to share on your demo ? Tx

[eirikb]

@hhertogh That's great!
I had to use the { displayInIframe: true } and without it didn't work.
My other coworker also experienced it hanging, so something is not quite right, at all times - but this was just a hack, since it works sometimes I'm pleased.
haven't done any more tests. I'm hoping for some feedback from Microsoft, and a proper solution.

[oscarcosta]

Hi,
I am having the same issue here. The pop-up authentication works fine on Outlook Web and Android App, but it is not working in the Outlook 365 on Windows or on the IOS App.

@eirikb not sure if you figured out how to get the Outlook version is running, but I think you can use this interface Office.context.mailbox.diagnostics.hostName.

[eirikb]

We are about to release my hack to production, as we have no other choice.

I've updated my demo, and made it runnable for others to test, in order to find bugs.
Add this manifest as Custom add-in:
https://eirikb.github.io/msal-outlook-demo/manifest.xml
Repo: https://github.com/eirikb/msal-outlook-demo

@oscarcosta Using the version is a good idea, as the normal msal login would be safer to use when possible. However for me it now failed on Edge (_Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134_) with a completely different error, but worked fine with my hack.
We're probably going to use the hack as default, with normal msal popup as fallback.

_Update 2020-01-28:_
Just noticed that sometimes the popup would not detect the hash.
This because MSAL will, for some reason, pick up the hash and redirect the page to "itself", before my script is able to pick up the hash and send it to the main frame.

_Update 2020-02-04:_
We've been testing the hack for about a week now (since last major change, ref last update) and it seems to work.
Tested in:

• Windows
  
  
  
  • Native: OK
  
  
  • Chrome: OK
  
  
  • Firefox: OK
  
  
  • IE11: OK
  
  
  • Edge: Ish, might need manual config
  
  
  • Edgium: OK
  
  
• OSX:
  
  
  
  • Native: OK
  
  
• Linux:
  
  
  
  • Chrome: OK
  
  
  • Firefox: OK
  
  
• Android:
  
  
  
  • Native: OK
  
  
• iOS:
  
  
  
  • Native: OK
  
  

[mpetro-t]

Is there any timeline or official feedback/workaround from Microsoft about this bug?

[frnk01]

Hope this is fixed asap. Can you share any timeline @jasonnutter @sameerag ?

[oscarcosta]

Hello @jasonnutter @sameerag, any update on this subject?

For my application (React with Typescript) the @eirikb's hack only solved the issue in the Outlook on IOS. So, I still unable to login using Outlook Desktop on Windows or Outlook Web on Edge.

Thanks.

[eirikb]

@oscarcosta Did you try the latest version of my demo (updated 2020-02-04)? We've deployed it to production and it works for us on all platforms except old Edge.

[oscarcosta]

Hi @eirikb just updating here. Your solution worked for me too! Thanks! There was a typo in one of the in the manifest.xml file that was preventing the message to be returned to the event handler.

[DarylThayil]

@hhertogh Jumping in, Are you using Electron in the outlook client? Or is your native app opening a web browser containing msal js? Trying to understand the whole scope here.

[hhertogh]

Hey,
@DarylThayil : No, we are not using Electron, it's the native app, in which the iframe is containing msal.js.

[DarylThayil]

So the truth is, this scenario is not currently supported in the library. We definitely have plans to enable Native Embedding scenarios, but it requires a few features before we can get there that we are still planning.
I

[ITSTord]

@eirikb Have you tested this with MFA? We have tested your "hack" with our outlook addin and it works fine in the OWA but Outlook Client on Windows we do experience that it just skippes past MFA and fails. I guess it can be edge related since the Outlook client is Edge HTML based.

[eirikb]

@ITSTord Yes we have tested with MFA and it works (Version 2003 Build 12624.20466).

[rdbartram]

I'm having the same issue using msal-angular. Everything works fine using Outlook in the Web. In the desktop client though, redirect opens the browser and doesn't go back...and popup shows the same screenshot and the original post. I feel people are suggesting its working. Can someone please point me in the right direction? thanks

[jasonnutter]

@rdbartram The fix for this issue will be included in 1.3.2, which will be released soon (this week).

[eirikb]

@jasonnutter This is great news! :balloon:
I wanted to give it a go so I pulled this repo and built lib/msal-core. My app runs, and the popup window opens up in Outlook native so something is working as expected, but the login process loops (let me choose account, shows loading, then let me choose account again).
It works fine in a browser (Firefox).
Do you have any demo code I can use to test? This is the code I used.
Tried with dev and release-1.3.2 branches.

Just for fun I tried with @azure/msal-browser as well (also built locally, from release-1.3.2 branch).
This worked flawlessly in a browser as well (Firefox), but in Outlook native the popup just shows my app within the popup, and trying to call API fails with "No tokens were found...". Here is the code for this test.

[jasonnutter]

@eirikb Can you please open a new issue for this behavior, thanks!

[eirikb]

@jasonnutter Should I wait for 1.3.2 to be released? It's a very high probability I've messed something up on my side.
Also noticed that the Outlook I tested with was updated to have Edgium.

[jasonnutter]

@eirikb 1.3.2 is available on npm and the CDN.

[rdbartram]

@jasonnutter just so I know, how does 1.3.2 make its way to msal-angular?

[jasonnutter]

@rdbartram msal is a peer dependency of @azure/msal-angular, so your application will be responsible for providing the updated version of msal.

[fkranenburg]

I have version 1.3.2 but msal still opens up my default browser (Chrome) and redirects to the page of my add-in in Outlook. This is somewhat unexpected behaviour. How can I display it inside a nice dialog?

[jasonnutter]

@fkranenburg Can you please open a new issue with your question, thanks!