0

I created a new ASP.NET MVC WebApplication in Visual Studio 2015 with the options to use School or Work Accounts to authenticate against an AzureAD. This worked fine.

Then I converted the Project to an App for Office Project as an Excel Task-Pane Add-In.

Then when I start the Application it starts an Excel Spreadsheet with a taskpane showing the request to login with Microsoft. When selecting an account or choosing to log-in with another account I get redirected to login.mocrosoft.com in a new Browser but receive the following error:

IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.

The URL shown in the new browser is "https://localhost:44300/" since I am debugging locally I take it.

Is this an issue because the authentication originates from the Task-Pane? Is the Task-Pane the same as an iFrame? If so it could be a similar issue as the following problem: OpenIDConnect Azure Website hosted in an iFrame within Dynamics CRM Online

Can I simply set the RequiredNonce to false? If so how?

Please help me to create an App for Office with Authentication against an AzureAD / Office365Domain? The AzureAD I am authenticating against is my private Free MSDN Subscription currently, wanting to use the company's Office365 AzureAD in future.

I am using Office2016, VS2015, Microsoft.Office.js Version 1.1.0.9.

Community
  • 1
  • 1
Bastien
  • 1

2 Answers2

0

First, it is feasible to do what you are looking for, have a look on my add-in: Keluro Mail Team. Keep on working, you'll manage to make things work^^.

Step1

First, start with the most simple scenario: your auth process should work in a standard window we sill see the sandboxed iFrame later. Check your OAUTH flow when browsing your 'app directly', i.e. test your authentication as a plain regular web app which is served in your case at https://localhost:44300/". To avoid javascript errors remove all Office.js related stuffs and the Office.Initialize function.

From the error message dealing with Nonce, I bet you are implementing a code authorization flow. This should be more or less something that looks like this sample. In this code authorization flow, the token and the REST requests are made by your server using an authorization token. Meanwhile authentication between your server and your web app is made with a plain old asp.NET cookie (in the sample above at least). This scenario is OK for our purpose, I use it too. To complete this step, try to request some basic stuff that is not related with Office.js but only with the Office 365 REST api. In one word forget that your developing and Office add-in, image you are developing an Office 365 web app.

Step2

Now that you completed Step1 you can go for step 2: make things work in a sandboxed iFrame within Office. Have a look at this blog post from Richard DiZerega. This is the most reasonable approach to handle OAUTH flow in a sandboxed environment. If you are using the sample mentioned in Step 1 above, the authentication between your server and your app is made using an asp.NET cookie. Following, Richard's guideline you could keep it in a server-side cookie dictionary after the popup OAUTH flow is completed and then set it in a request from the original iFrame. To recognize that the two windows correspond to the same user you can generate (cryptographically secure!) an id that you can pass in the two requests (parameters are encrypted in https). Ok that is complicated but it works. The SignalR technique Richard talks about is a plus for user experience but is not mandatory, that could be a Step3.

Benoit Patra
  • 4,355
  • 5
  • 30
  • 53
  • Hi Benoit,thank you for your hints. I am new to this and could not follow everything. However I did try and surf to the webApp as a normal Webpage and this works fine. To get the Office-Add-in to work I added the https://login.live.com domain to the App Domains in the manifest. Why this works I cannot say because I do not understand the technology behind it, but nonetheless can continue with my app. – Bastien Jan 25 '16 at 11:50
  • adding the login.live.com domain to the app allows the app (which lives in a sandboxed iframe) to browse to this url (without it, the sandbox same origin policy would prevent it). So it looks a good idea but it does not work in this precise case which is a login screen: as Vitorio wrote http://stackoverflow.com/questions/29378683/openidconnect-azure-website-hosted-in-an-iframe-within-dynamics-crm-online, this login screen page cannot be iframed to prevent click jacking. – Benoit Patra Jan 25 '16 at 12:29
0

I solved my issue by adding https://login.microsoftonline.com and https://login.live.com to the App Domains in the App Manifest. I dont understand the technology, so I cannot comment on why this works, but the solution works for me.

Bastien
  • 1
  • I am glad you found a workaround. However, I am still a little bit curious. You managed to do the OAUTH flow in your office add-in without any popup? Maybe a cookie/token is still present in the browser cache. Did you try with different browser and after cleaning your browser cache (cookie and localstorage at least)? Does it work with Office desktop? – Benoit Patra Jan 25 '16 at 16:22
  • I just checked login.microsoftonline.com and login.live.com are served with *X-Frame-Options:DENY* which means they should be able to be displayed on your app window (sandboxed iframe). Which browser are you using? – Benoit Patra Jan 25 '16 at 16:25