Guidance for use in Outlook

[elegault]

I'm having issues trying to use this library in an Outlook web add-in with Azure AD. I can get the auth dialog to popup and have the user login and then authorize the application. However after that step (and subsequent retries) the auth page displays the "Sorry, but we're having trouble signing you in" page with this error:

AADSTS50011: The reply address 'https://mywebapp.azurewebsites.net' does not match the reply addresses configured for the application

The full issue is documented here: https://stackoverflow.com/questions/47276315/problems-with-azure-application-manifest-trying-to-authenticate-with-office-js-h.

What exactly is the relationship between the add-in's url and the Reply URL for the application manifest (I have the same for both)? That seems to be the core of the problem but I can't figure out what else it should be.

A secondary issue is that the auth popup doesn't appear when the add-in is hosted in a browser (it only works with Outlook desktop). I see a DOM error about blocking a cross-origin frame. Can the helpers be used at all from the browser?

[WrathOfZombies]

So the issue here is that your Azure AD application has been set to redirect the user to a registered redirect_url with the user's token. This is done for security reasons.

However in OfficeHelpers, for convenience, we auto set the redirect url to your current application's domain, in this case, https://mywebapp.azurewebsites.net. In order to solve this please copy the redirect_url as is and use the advanced config as:

// set the redirect url by providing the config object.
authenticator.endpoints.registerMicrosoftAuth('client id here', {
    redirectUrl: 'redirect url here'
});

As for your issues with the browser execution, I have already started work on a new variant of this where it should resolve the cross-origin frame issues. I have received some feedback and I am trying to rectify the code while remaining backwards compatible.

In the meantime you can try the beta version here: https://unpkg.com/@microsoft/office-js-helpers@0.8.0-beta.4/dist/office.helpers.js

Please try it out and let me know..

[elegault]

Note that I have been using registerAzureADAuth, not registerMicrosoftAuth, as Exchange Online permissions cannot be set using the latter type of application AFAIK. I had tried using the redirectUrl parameter with registerAzureADAuth but it didn't work (perhaps because I also included the responseType: 'id_token' parameter and value, which I'm not sure is incorrect or not). Should I try again using registerAzureADAuth and just the redirectUrl parameter? Also, it's not clear to me what I should use as the url - the domain only or the add-in's page url? If it's not the add-in URL will it still try to redirect to the default page at the root?

[WrathOfZombies]

Let me break this down into multiple replies.

what I should use as the url

Please use a url that you'd want your users to be redirected to after login. This can be the default page at the root or a custom page saying authenticated. The only significance of this is that on AzureAD you're telling to send the user with the token back to this page and on the Add-in, we are waiting for this page to appear in the popup so that we can know when to close it automatically.

No matter what you decide, both the redirectUrl property and the redirectUrl set on Azure must match for a successful authentication.

Note that I have been using registerAzureADAuth, not registerMicrosoftAuth

Doesn't make a difference as all helpers registerXAuth use the same underlying code. So the overrides work consistently.

(perhaps because I also included the responseType: 'id_token' parameter and value, which I'm not sure is incorrect or not)

There's an active bug that I need to investigate (#54). Probably related to that.

Should I try again using registerAzureADAuth and just the redirectUrl parameter?

Yes please try that.

[elegault]

Thank you very much - I will get on all that!