1

Using Microsoft's Sellers Dashboard, I've created and published an Outlook (office365) add-in. I've also created ClientId and used it to work with api. For about one year everithing was fine, but several weeks ago I faced error when I was trying to get Access Token. The error said that my Secret Key is invalid. So I went to Sellers Dashboard, deleted secret key and created new one. Somehow, this procedure also changed my ClientId. Anyway, I've tried to use new ClientId\SecretKey, but now I'm getting another error, which says that there is no app associated with specified ClientId. So the question is: where is the setting, that associate ClientId with add-in?

Thank you in advance

Andrey
  • 11
  • 3
  • Hi Andrey, I did not noticed that Microsoft Sellers Dashboard was providing clientID. It is for the Office 365 web api? How did you manage to implement the OAUTH flow? I had many problems with the same origin policy, see [my post](http://benoitpatra.com/2015/05/28/implementing-the-oauth-2-0-flow-in-app-for-office-sandboxed-environment/). Did you use a popup ? – Benoit Patra Sep 16 '15 at 09:40

1 Answers1

0

To answer your question

where is the setting, that associate ClientId with add-in?

Normally, if you use plain Azure AD (which seems to be the tech stack behind the scene) there is no association between clientID and your addin. The clientID is associated to a domain, this should be the domain under which the app website is served.

Edit: however in the case of the Microsoft Seller Dashboard, it looks like there is a MARKETPLACE APP field, but I do not know how to set it, see. enter image description here.

Then, to solve your problem, if you look at the screenshots you can see that there is a way to renew the client secret on a given clientID. Maybe you can still use the old clientID and drop the new one. It seems that you cannot have access to the azure ad app manifest (do not confuse with you app manifest), to see what is going wrong. I think you should report to Microsoft Seller Dashboard.

If the previous solution does not work, I believe that your best alternative is to use an Azure AD and enter your application as a multitenant app.

Remark about manifests.

You probably know that, but keep in mind that an office addin (new generation, formerly an app-for-office) is only a tiny xml file called manifest and the "real" app is a "website" that serves your app (html,js, css files). In the manifest you'll find some information about the app: size of the iframe, supported languages... and, more importantly, the app url. Everything, that is related to authentication to a web API is handled by the website app. The manifest is not aware about that.

It may be possible, that you are testing with a local website (or multiple ones), then the domain and callback url registered in the Microsoft Seller Dashboard does not match your testing environment. Check also that the office 365 account that you are using uses the right manifest (that points to your testing website with the new client ids).

Finally, there are two places where the manifest can be registered in Office 365. Clean everything before installing your new one, to test.

1) at admin level (office 365 global admin installed an app for the whole organization) Admin > (Left Frame) Admin/Exchange > Organization > add-ins Admin administration of addins

2) at user level (the user installed an app for himself) Mail (outlook.office365.com) > (gears at right top) > Manage add-ins User administration of addins

Benoit Patra
  • 4,355
  • 5
  • 30
  • 53
  • Yes, I'm using id and secret on the server side. Domains are the same. But then I'm trying to call https://login.microsoftonline.com/common/oauth2/authorize, it returns following error: AADSTS70001: Application with identifier [provided clientid] was not found in the directory [subdomainOfOffice365User].onmicrosoft.com. The intresting thing: then I'm trying to use old clientId, it returns different error saying that secret key is wrong – Andrey Sep 16 '15 at 12:16
  • I have updated my answer. Hope this helps. Meanwhile, could you give me an hint, on how did you manage to implement the OAuth flow in the sandboxed environment of addins? – Benoit Patra Sep 16 '15 at 13:18
  • When user clicks link in his email, outlook redirects him to the callback url. In callback method I make a new redirection to login.microsoftonline.com/common/oauth2/authorize with clientid etc. As a result, I got some Code, which I use to recieve access token. I just pass the Code with secret key, recieve token and use it to get email body. Is it what you mean? – Andrey Sep 16 '15 at 14:45
  • Yes, this what I mean. It looks like a well implemented OAUTH flow. However, I could not manage to implement the same because the app-for-office addins are sandboxed html5 iframes preventing CROSS domain navigation. You are sure that your flow did not need a popup window to work? see this [thread](https://social.msdn.microsoft.com/Forums/office/en-US/c36a1706-e1b8-4d29-96ce-b52fe774c692/what-is-the-recommended-solution-for-implementing-the-oauth-20-flow-in-sandboxed-app-for-office?forum=appsforoffice). Can you name your app so that I can test my self once your clientid problem will be solved? – Benoit Patra Sep 16 '15 at 20:49