Search code examples
outlookoffice-jsoutlook-addinoffice-addins

Office.js - How to get more information about error 13006

I'm working on an Office add-in for Outlook. Currently, it works when I run it locally in both OWA and in Outlook desktop.

When I deploy it and run it without debugging, in Outlook desktop I when I try to start the add-in I get this message:

I think this is happening because SSO is failing and it's trying to fall back to MSAL auth, and this is not working correctly in Outlook desktop (a little more on this below).

My reasoning for this is that when I run it in OWA, I get the MSAL popup, and I can see the following error logged:

Office auth failed, falling back to MSAL.
Error:  OSF.DDA.Error 
{
    name: 'Error occurred in the authentication request from Office.',
    message: 'An unexpected error occurred in the client.',
    code: 13006
}

The first line is my own logging from a catch block around Office.auth.getAccessToken(). However, the add-in does work fully as expected in OWA after this, including authenticated API calls (and I can see the token as a header on these requests). But as mentioned if I try to run it in Outlook desktop, I get this dialog, and it does not fall back to MSAL.

As a quick aside, I don't think this should happen, as I have it configured to allow the sign-in prompt and consent prompt: token = await Office.auth.getAccessToken({ allowSignInPrompt: true, allowConsentPrompt: true, forMSGraphAccess: false });

So even if SSO fails, users should still be able to sign in. But one problem at a time.

When I was initially testing this, I saw similar behaviour, i.e. I saw this error logged in OWA, and I would get this dialog in desktop. However, I solved that problem in OWA by ensuring that all the domains in my manifest matched (in terms of source, listed in the AppDomains section, and in the Application ID URI in the app registration in Azure). When I don't see this error in OWA, I don't get the dialog in Outlook desktop.

I thought this might be relevant because obviously when testing locally the domain is localhost, and it's not this when deployed, so this is something that is different between the two. However, every URL is correct in the manifest as far as I can tell. The only difference is in contacting the back end - when running locally it looks a little like this:

Component Local Deployed
Addin localhost:3000 plugin.mydomain.com
Back end localhost:4000 app.mydomain.com

I have mydomain.com, app.mydomain.com and plugin.mydomain.com listed as app domains in the manifest. I have also verified that the app registrations, app IDs, and scopes are correct in Azure, because a) it works in OWA and b) it works in the back end app (which has it's own SPA UI).

What else do I need to check? And how do I get more information about what's causing the 13006 error?

EDIT: Still working on this but I think the problem is that the back end and add-in need to be running from the same domain/sub-domain. This is going to be a PITA for deployment if true, but may be the cause of my issue. Will confirm.

Solution

  • As suspected, this issue was caused by different sub-domains. In the manifest, you specify a Resource which is Application ID URI in the app registration in Azure. The domain and sub-domain of this URI must match the domain and sub-domain of the URI your add-in is loaded from.

    In my case, the add-in is loaded from plugin.mydomain.com, but it communicates with a back-end at app.mydomain.com. So the Application ID URI was api://app.mydomain.com/[some guid]. This effectively breaks SSO (although MSAL still works).

    There's not really any way around this, other than hosting my back end and add-in from the same sub-domain. So as a simple workaround, I've just changed the Application ID URI in my back-end registration to api://plugin.mydomain.com/[some guid] and now SSO works, and I can use the add-in in OWA and Outlook desktop. It's pretty inelegant, but it's the least of the compromises I've had to make to get this working.