Using Azure AD to allow Authorized CORS Access to O365 data

In this article I will show how to to create an Authenticated way to access O365 data from an Azure website. This method creates the necessary CORS headers to allow cross domain AJAX data traffic.

This whole article is based on the following site Create JavaScript web apps using CORS to access Office 365 APIs. I wrote this article because it was not at all clear to me from the Microsoft posting how everything fit together and I had to go through it a number of times to figure it out.

The article and screenshots are accurate as of 31 Jan 2016 and may change over time.

Setting up Azure AD as your O365 directory

For a more in depth description of how to use Azure AD as your directory for O365 check out this excellent support article. This is also a very helpful link – What is Azure AD Directory? it will help you describe how to assign your Azure AD to your MS Cloud account.

Once you have the Azure AD directory set up you can manage it though the Azure portal. In there you can find your directory by scrolling to the bottom on the left and selecting Active Directory.



Adding a new application

Select Application at the top of the screen and select Add at the bottom


Add an application my organization is using


Give it a name


Give it a sign in URL and and APP ID URI (“The App ID URI is a unique identifier for Azure AD to identify your app“)


For the sake of this demo the above values are arbitrary and make more sense in context of the overall configuration.



Select Configure at the top and look at what was created

App configuration

The configuration section shows all the information you need, and you application needs to be able to access O365 data from your application. This does NOT have to be an azure hosted application. I am just using Azure for the sake of convenience.

The name and Sign-on URL are carried over – the Sign in URL is actually merely for convenience, you don’t need to use it as far as I can tell.


The Client ID – this is the single most important piece of this puzzle – this key holds the application together. You send it as part of the request for Authorization token. With it O365 determines the what who why when for security.


In the Single Sign on section below we see the App ID and the Reply URL (which is the Login page URL)


We are going to change the reply URL to be the App ID for convenience. Don’t forget to save!


We have to give the demo.html application access permissions inside of O365

Adding permissions to applications

Selecting Add Application brings up all the applications being managed by Azure AD directory.


We are going to change permissions to access SharePoint online. Select and continue..

Select the delegation permissions. In this case I blanket added all permissions just for the sake of not having to explain everything. You probably want to make sure that you understand what permissions you are exactly giving the user. Remember once you create the authorization, users can write their own JavaScript and do not have to do what you want them to, they can do what you authorize them to do.


and don’t forget to save…..remember this, otherwise you will waste time wondering why you are an idiot….

Changing the manifest

The manifest file is available at the bottom of the screen – selecting the link will download the text file.


Looking at the manifest we see the true textual representation of the configuration. The important part here is to allow the application to allow the OAuth token to be returned to the user so it can then be used for further data requests. If you do not make the following change the example application (see below) will return the following…


To correct fo this issue, change the following line to true

“oauth2AllowImplicitFlow”: true,

Save the manifest and upload it again.

Creating an application

Following the methodology from the previous article, I created an Azure HTMl5 app with source control integration and loaded the example files up to the demo.html page.

The demo Application

The end product looks like this.


Click the button to get the OAuth Tokena17

The Token is returned as part of the URLa18

Clicking the CORS Request button collects data from the default site collection on the O365 account.

We do not need to make this a 2 step process though, in later article we will show how to create the results in the form of an angular ui-grid



It is a little convoluted to create and set up an “Application your company is working on” and make it use O365 Authorization and Authentication. But once you go through it the first time it becomes relatively east to remember.

We were able to request O365 data on from a site not in the same web domain,

This is the first example and I will be writing more about how it all fits together in the future.












4 thoughts on “Using Azure AD to allow Authorized CORS Access to O365 data

    • John – thanks for leaving a comment 🙂

      This is kinda an evolutionary work in progress, but which part are you looking for?

      The base code is pretty much the same as in the Microsoft example just with a different end point for a SharePoint list rather than One Drive as in the example. The SharePoint integration with Angular UI part I will be blogging in the near future.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s