O365Token GitHub project – Authenticating Office Add-Ins to Azure AD using only JavaScript (No C#)

In this article I will discuss the first iteration of the new GitHub project I created for the O365Token generation. The project is a generic code sample which can be added to your Azure AD websites and ultimately used to create a secure sample Add-In. We will look at how to take the sample code in the GitHub repository and deploy it to your environment.

Introduction

In the previous article I showed an alternate method for creating an authorization token from within the Outlook client. After receiving encouragement from Simon Jaeger I decided to continue and make this into something to hopefully collaborate on with others.

Github O365Token

The repository is hosted here – https://github.com/markyroden/o365Token – clone it to wherever you want (I use Webstorm IDE) and follow these steps:

  1. Using the instructions posted here, create your Azure AD site and make the redirect URL match the sample/index.html path.
    e.g. https://yoursite.azurewebsites.net/sample/index.html
  2. Modify the following token parameters in app.js to match your application
    • clientid
    • resource
  3. Run

 

How it works

In this version of the token generation I combined a number of aspects of the code and streamlined them to work as one file. There only 3 files (not including CSS) involved in this O365Token sample.

o1

  • Index.html
    • The place holder for the Add-In
  • Home.js
    • Determines if the code has been opened in an Add-In or as a popup token generator
  • App.js
    • If the page opens as an Add-In it causes the pop-up token generation window
    • If the page has been opened in the add-in it acts as the recipient of the token generated in the popup

Combining code

To simplify deployment and maintenance over time I decided it was easier to write the token generation code into the add-in itself. This also helps to reduce the number of changes necessary

Index.html

Index.html is really just the placeholder for the sample code – all that happens is that it ends up displaying the token once it is generated.

Home.js

We are using the same /index.html as the Add-In and the popup token generation window as well. The Home.js file determines if index.html has been opened as an Add-In and if so, calls the app.getToken code. If index.html has been opened in the browser the app.returnToken is called.

o2

App.js

App.js has three functions:

  • app.getToken
    • Called when index.html as been opened in the Add-in
  • app.returnToken
    • Called when index.html has been opened in the popup
  • app.tokenCallback
    • Called from the app.return once a Token has been generated. This is where your actual Add-In code would live in the future.

o3

For the Future

I have a feeling that this ought to be an Angular module. I can see a lot of Add-In code being written as an Angular app and as such it would make sense to include the app.requestToken and app.getToken as something which can be hooked easily into any other angular app.

 

 

 

 

Advertisements

Simplifying O365 Outlook client Add-In Authorization without C#

In this article I will demonstrate a simple method for getting an Authorization into and Outlook Add-in without writing any C# code. I will also highlight some of the problems involved and how the solution elegantly overcomes this.

Introduction

In the previous article we looked at how the How the example O365 Authorized CORS application works and in that example is a location.href change which works just fine within a web browser, but fails badly as an outlook client Add-in.

When the example CORS application is packaged and deployed as a client Add-in it appears to work until you click the “Get Token Button”. The location.href change causes an Internet Explorer window to open, where you can log in……but the end result is you being in an Internet Explorer Window and the token is not in the Outlook Add-in.

A recognized way to solve this issue 

Simon Jaeger has written a number of excellent articles on how to create Outlook Add-ins through Visual Studio and writing some C#

http://simonjaeger.com/developing-outlook-add-ins-where-to-integrate-and-what-you-can-do/

http://simonjaeger.com/building-a-good-authentication-flow-in-an-office-add-in/

The guys in my team tell me that those are a pretty sweet solution to the problem, but my problem is I am not a C# developer and have no desire to become one.

What Simon’s code did do though, was was to inspire me to try something different.

Solving the problem without C#

As I understand it Simon’s example opens an authentication window and then passes the authentication token back to the Add-In via SignalR

 // Show prompt in a new window
    window.open(redirectUri.replace("signalrid", signalrId), "",
        "menubar=0,location=1,resizable=1,scrollbars=0,status=0,toolbar=0,width=550,height=600");

But it struck me that the window.open opens the possibility for the open window to communicate with the opener. (Yeah I know that’s a dumb sentence but it is accurate).

So I put it to the test. I created a button on my sample index.html and made the deployment as an add-in

c1

The code on the button – dead simple – open the window on itself (it really doesn’t matter which site)

<button onClick="window.open('https://xomino365.azurewebsites.net/o365/index.html')">Open Window</button>

Looking at the open window we can bring up developer tools and use the console to test if window.opener is null.

c3

and it isn’t.

So then let’s do a test – let’s see if we can manually stick a value back into the opener……and it did !!

c4

Well in that case we are all sorted !!

Modifying the example code

I am modifying my existing code for the sake of a consistent story, this is not how you would do it in production.

  • If the index.html opens and window.opener is not null I call the function to requestToken() automatically.
  • The page reloads
  • If the page loads detects that we have a token, and we have a window.opener, it
    • Sends the token back to the Outlook client Add-In
    • Hides all the buttons
    • Clicks the Make CORS Request button automatically
    • Closes the popped up window
            if (window.opener){
                window.opener.document.getElementById("TxtOauthToken").value = token;
                window.opener.document.getElementById("doCors").style.visibility = "visible";
                window.opener.document.getElementById("doCors").click()
                window.opener.document.getElementById("getToken").style.display = "none";
                window.close()
            }

And that’s it – the user either sees a quick popup and then the Add-In gets the data from SharePoint. If they have not checked the “keep me logged in” box, or have had their login expire, they see a log in screen where they authenticate with O365 SharePoint, the window then closes and runs in the Add-In.

c5

Conclusion

In this article we have seen how to use a window.open from within our Outlook Add-in to be able to create an Authorization token which can be passed back to the Add-In and used to get Cross-Domain SharePoint data from O365.

In a future article I will streamline this code to create something which can be used for just authorization and is not the same webpage as the Add-In.

 

PS

If you have never done this before you may be prompted with the following dialog – which MAY come up in the background as well. You need to (and tell your users to ) check the box and Allow this in the future.

c2

PPS

I also discovered that you can use WebSockets to transfer data “into” the Outlook Client Add-In. This turned out to be unnecessarily complex and raises some security concerns – but – makes for some excellent ideas for future Add-In functionality ideas.