Working Sample?

[elthombre]

In the following article:

https://docs.microsoft.com/en-us/office/dev/add-ins/develop/dialog-api-in-office-add-ins

there is an image of a dialog that uses an external sign-in process. A secondary article:

https://docs.microsoft.com/en-us/office/dev/add-ins/develop/auth-with-office-dialog-api

discusses the technology.

Why is there no fully working sample? I would assume a couple of things:

• a lot of folks might want to leverage a 3rd party provider such as those referenced in the dialog image shown in the above article.

• one can also assume that many may have their own website or authentication model that they want to leverage as the 3rd party sign-in. For example, why not a sample that has an ASP.Net site the integrates for authentication / authorization with an Office add-in?

Lastly, many of the samples referenced in these articles do not appear to be using the latest add-in technologies.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 79a7a8a4-186e-ced9-4e4c-e78437dd59ba
• Version Independent ID: 34044d2e-25ec-6893-edfa-0a51730dc60a
• Content: Authenticate and authorize with the Office dialog API - Office Add-ins
• Content Source: docs/develop/auth-with-office-dialog-api.md
• Product: non-product-specific
• Technology: add-ins
• GitHub Login: @o365devx
• Microsoft Alias: o365devx

[Rick-Kirkham]

Reassigning to @davidchesnut because this is an auth sample request.

[elthombre]

Hi, ideally, an add-in that runs within OWA (Outlook web app), that pushes a dialog whereby an external website is used for auth and, if successful, redirects to the add-in taskpane.

[KelBowen]

@davidchesnut OK to close this issue yet?

[davidchesnut]

Hi @elthombre I apologize for not getting this answer posted sooner. I thought I had posted awhile back, but I dont see it here, so I must have missed this somehow. The dialog is based on an archived sample here: https://github.com/OfficeDev/Office-Add-in-Auth0 If you reuse the code just be sure it is up-to-date with latest library versions and security recommendations. We're moving away from these sorts of samples that are more about non-Office technologies such as Auth0 or MSAL which already have their own documentation. For example, MSAL and Microsoft identity have a ton of samples across multiple platforms and scenarios. It makes more sense to reuse those samples, rather than reinvent them all in an Office context. Separate from this issue, the team is working on providing guidance on how you can take those samples and adopt them to Office (through the dialog API).

Hope this helps! David

[elthombre]

@davidchesnut , the problem with those recommendations is that under the circumstances those examples represent, the developer has complete control of the entire application, right? The application is built from scratch and those samples provide guidance for sign-on.

As an Office developer, we do not have control of the pre-existing environment. Meanwhile, the demands placed upon us are to extend and to customize. Sign-on is only one aspect.

[davidchesnut]

Hi @elthombre, to be clear, when you mention the "pre-existing environment" are you referring to the M365 tenant where your add-in is deployed? As long as the admin consents your add-in should work correctly with the users on that tenant. Most of our guidance is built around using the on-behalf-of (OBO) flow. So I would recommend starting with the samples that indicate they use OBO. For example, Call Microsoft Graph via OBO.

[elthombre]

@davidchesnut , no, what I am saying is that these samples related to authentication are segregated from the solution in question. If I'm building a web app or mobile app or desktop app from scratch, etc., I can control the entire experience and have access to the entire project. In MS Office development, one is working within a pre-existing environment where limited aspects may be exposed.

[davidchesnut]

Ok, so referring to the sandboxed environment of the task pane running in a webview (desktop) or iFrame (online)? That is true that unlike VSTO solutions you'll be more constrained to just working with the Office.js APIs (or browser features.) Auth will continue to work, and you can use SSO so you don't have to sign in the user twice. Is there a specific challenge you are running into with building an Office Add-in?

[elthombre]

@davidchesnut - my apologies here, I've been working on something new related to Teams. This thread was originally created over a year-and-a-half ago. What I presently face is different but I will add that the demands of the client at the time of the original post created some constraints that did not align with Microsoft's recommendations / best practices.

[davidchesnut]

Hi @elthombre, there is documentation about Authorization with non-Microsoft identity providers as well as Authenticate and authorize with the Office dialog API. As you point out you don't control the entire app as Office is loading your code into a browser runtime, so there are limitations covered in those articles. I have been working on the samples to keep them up to date with latest MSAL changes.

I'll close this issue for now, but if you see any additional issues I should address in the samples or docs, can you please let me know (reopen)? Thank you!