SPFx 1.6 was released recently with new features which support secure connection to Azure AD protected APIs. During upgrade some things in your tenant and Azure AD were changed. For some users migration didn’t go smoothly and they saw strange errors in different places. I’m in the group of users who experienced errors and had to fight with them. Fortunately really smart guys from Microsoft and community resolved everything. There are a few issues on GitHub related to SPFx 1.6 errors. It might be difficult to go through all comments and find an answer on your concrete problem. I see that more and more people struggle with the same types of errors, I sum up potential errors and their resolutions in a separate post.

Basically there are two types of errors you might see when trying SPFx 1.6 features. They are described at GitHub SPFx The user or administrator has not consented to use the application with ID and SPFx suddenly stopped working; experimental feature error. More...

- Classic pages you said?

- Yes! You read it right. MS Graph API from classic SharePoint page. However please read it first:

That’s not an official or recommended way. That’s just a proof of concept, which uses some tenant features introduced with SPFx 1.6. That’s something I decided to try out when SPFx 1.6 was out. Use it on your own risk.

When to use it? On classic pages if you don’t have an option to execute SPFx code.

So what if you want to call some MS Graph APIs from your classic SharePoint page? No problem then.

Before doing actual coding, we should check that we meet all prerequisites:

• You have SPFx 1.6 features, which work without issues in your tenant. You can test it by creating a simple SPFx web part, which uses MS Graph. Upload it to the app catalog, approve the request to MS Graph and see it actually returns MS Graph data

If above works, you have everything needed for our experiments. More...

SPFx 1.6 was released recently and a lot of new and interesting features were introduced. AadTokenProvider, AadHttpClient, MSGraphClient  went to GA, which are my favorite features. One of the common thing in SPFx development is accessing other resources, protected with Azure AD. For example you might have your LOB API with Azure AD protection and you want to consume that API from SPFx web part (extension). Before SPFx 1.6 it was a bit challenging, because you have to deal with cookies attached to your asynchronous http request or with custom “patched” adal.js implementation. SPFx 1.6 features mentioned earlier drastically simplify the task to access Azure AD protected resources. Now you can access Azure AD APIs (including Microsoft APIs like MS Graph) from SPFx with ease!

I’m pretty sure you know about PnPjs library. It has a lot of cool features, among them a fluent interface to SharePoint and Graph API. WIth SPFx 1.6 release you can use PnPjs as your Graph client without hassle. Read further to find out how. More...

This year I hear “Web Components” term from here and there more frequently. What exactly is Web Components?

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

In other words, web components are reusable pieces of HTML and JavaScript, which can be used in modern browsers, and what is even more important, can be consumed by JavaScript frameworks. Today we have a few web frontend libraries for building web interfaces and SPAs. All of them uses concept of components, however components from one library can’t be easily ported to another one. It looks weird, because in the end that’s just portion of html + styles + logic (JavaScript). However today, in 2018 we can’t reuse building blocks from one library in another. It’s a shame. Web components solve that issue. They can be reused across JavaScript frameworks. Check out webcomponents site for more information.

Web components is a set of W3C standards, which describe how everything fits together in browser. Not all browsers fully supports all web components’ specifications. Google Chrome has full support, Firefox is developing a few remaining things and Edge has the worst support: More...

Consuming third party or your own Azure AD protected API from SPFx code is a very common need. I wrote a blog post series on that topic, the first one you can find here. All solutions I covered have their own pros and cons, however the less painful and recommended solution is AadHttpClient (available in SPFx 1.6 and onwards). AadHttpClient approach has less issues and works really good. If you are curious about how it actually works, read the rest of the post. In this post I dive into AadHttpClient architecture, libraries and technologies used, think about security issues and try to bypass (spoiler: successfully) webApiPermissionRequests restrictions in SPFx web parts. More...

Call Azure AD secured API from your SPFx code series:

1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials")
2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials")
3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js 
4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient <—you are here

This post covers the last and recommended way to interact with remote Azure AD protected APIs from SPFx code – AadHttpClient. As of now (Aug 2018) this feature is still in preview and not available for production. I guess it will be available in a few months, however that’s only guessing. Why it’s recommended? Because it’s OOB SPFx way to interact with APIs, it eliminates almost all cons we have with previous methods and it’s much simpler and solid. More info on this topic you can read here - Connect to Azure AD-secured APIs in SharePoint Framework solutions.

Source code for the post is available here at GitHub.

Today’s post covers:

1. New app registration in Azure AD (step will be taken from previous post)
2. Create Azure AD secured API (Web App with custom jwt bearer authentication or Azure Function with EasyAuth aka App Service Authentication, I will cover both) and enable CORS (step will be taken from previous post)
3. SPFx webpart, which uses API via AadHttpClient
4. Deployment and testing

As usual, let’s get started More...

Call Azure AD secured API from your SPFx code series:

1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials")
2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials")
3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js  <—you are here
4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

It’s possible to call your remote Azure AD secured API with help of popular adal.js library. This approach has a number of issues (read in the end of the post). Almost all issues come from a fact, that adal.js works well in case of SPA and doesn’t play nicely in SPFx world. To make it work with SPFx, you should “patch” it. Even in this case there are some caveats. That’s why for now recommended approach is using AadHttpClient, however for the sake of completeness I wrote a post on adal.js as well. By the way, AadHttpClient is still in preview (as of now, check the actual state at docs.microsoft.com).

Read more on this topic here – Connect to API secured with Azure Active Directory and here – Call the Microsoft Graph API using OAuth from your web part.

In today’s post we need to perform below steps:

1. Add new app registration in Azure AD
2. Create Azure AD secured API (Web App with custom jwt bearer authentication or Azure Function with EasyAuth aka App Service Authentication, I will cover both) and enable CORS
3. Patch adal.js library to work with SPFx
4. Create SPFx web part, which uses adal.js and calls remote Azure AD protected API

The source code for this article available on GitHub here.

Let’s get started More...

Call Azure AD secured API from your SPFx code series:

1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials")
2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials") <—you are here
3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js
4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

In the previous post, I showed an example on how to call Azure Functions API protected with Azure AD (using EasyAuth setup). Described approach has a few limitations, one which is the most important is an inability to send HTTP POST or PUT requests. This issue can be fixed by using regular ASP.NET Web API application with custom authentication layer. More info about this approach you can find here - Access the API by leveraging SharePoint Online authentication cookie. This post describes required steps to make it work:

1. Add new app registration in Azure AD
2. Create new ASP.NET Core application and setup authentication with Azure AD.
3. Enable CORS for your web application with credentials support (so we can send CORS AJAX and attach credentials to our request, auth cookie in our case)
4. Create simple SPFx webpart, which gets data from our web app via authenticated HTTP request (GET and POST).

The source code for this article available on GitHub here.

Let’s get started. More...

Call Azure AD secured API from your SPFx code series:

1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials") <—you are here
2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials")
3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js
4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

Imagine a very common scenario, when you need to send HTTP request to your backend API to get or store some data from your SPFx web part. Of course, you can’t leave your API without any authentication layer. Using Azure AD authentication for that matter is a very good choice because you leverage SSO within your organization. The question is, how to properly get an access to those API in a secure and seamless manner. One option might be using cookie authentication. This approach doesn’t use well-known library adal.js, at the same time it’s simple, however, has its own cons (read at the end of the article). More info about this approach you can find here -  Access the API by leveraging SharePoint Online authentication cookie. In another post, I will show how to do the same thing using SPFx’s AadHttpClient.

We are going to perform below steps:

1. Create a simple Azure Function in Visual Studio.
2. Create Function App and deploy our code to the Function App in Azure Portal.
3. Create new App Registration in Azure AD.
4. Setup Azure AD authentication for Function App.
5. Create simple SPFx webpart, which gets data from our Azure Function via authenticated HTTP request.

Let’s get started. More...