AtlasLogoWeb_5650x1115

Using a Kiota client for your API in a SharePoint framework solution

7 November 2022
  

In this follow-up blog to using Microsoft Kiota to create a client for any API described using OpenAPI, Luis Mañez looks at using a Typescript client in a SharePoint framework solution.

Hello there! It´s Luis Mañez.

In my blog "Using Microsoft Kiota tool to generate Atlas API SDKs" I introduced you to Kiota. I encourage you to read that article first but, in a nutshell, Kiota is a command line tool that generates the required code to consume an API described in OpenAPI.

In this blog I’ll take you through using a Typescript client, generated by Kiota, in a SharePoint framework solution. Different to when the client is in a dotnet project, in this scenario we don’t have an existing Kiota authentication provider that 'just works' in a SharePoint framework project.

Luckily, Kiota provides multiple abstractions, so you can plug in your own implementation of them. And in any SharePoint framework project we have a way to call any API secured by Azure Active Directory. This is the aadHttpClient object that can be obtained from an aadHttpClientFactory. That http client will handle auth for us and will add the proper Authorization header (you know: Bearer {access_token}).

In our first attempt we thought reusing that aadHttpClient in the Kiota request adapter would work, but the existing aadHttpClient doesn’t implement the expected interface from Kiota.

CTA: For an introduction to Kiota read Using Microsoft Kiota tool to generate Atlas API SDKs

Here is what we did then (and please note this might not be the only solution): we implemented the existing Kiota interface AccessTokenProvider, which expects that you implement a getAuthorizationToken (to be totally accurate there’s also another method to implement – getAllowedHostsValidator – but that´s not terribly relevant, and you can see the code later). This is the contract of the getAuthorizationToken:

getAuthorizationToken screenshot

Basically, you just need to return a valid access token for the requested API. The SharePoint framework already gives us an object to make authenticated calls, but here we just need to return the token. Fortunately, another object provided by the SharePoint framework allows us to get a token. AadTokenProvider, which again, can be obtained from the AadTokenProviderFactory. This object has the following method:

AadTokenProviderFactory screenshot

Where resourceEndpoint is the Application ID URI of the app registered in Azure Active Directory for the API that you want to consume (for custom APIs, usually it looks like: api://{aad_app_client_id}, or for Microsoft Graph API, it will be: https://graph.microsoft.com).

Now that we have an object provided by the SharePoint framework that will give us the required token, we can use it in our custom Kiota AccessTokenProvider implementation. How? Well, we pass the SPFx AadTokenProvider to our custom AccessTokenProvider in its constructor. Using this technique, we can also pass the required Application ID URI.

AccessTokenProvider implemention screenshot

Now, the getAuthorizationToken, just needs to call the SPFx AadTokenProvider getToken method:

SPFx AadTokenProvider getToken method screenshot

We are done with our custom AccessTokenProvider, however, we need one extra step, as our Kiota client requires a RequestAdapter, and the RequestAdapter requires a Kiota AuthenticationProvider.

The Kiota team provides us with another interface to create an Auth provider: AuthenticationProvider. And we have a base class that implements the interface and helps us create our child class: BaseBearerTokenAuthenticationProvider. Now we just need to set up our child class to inherit from BaseBearerTokenAuthenticationProvider. The only code we need in our class is for calling the parent constructor, providing an object of our custom AccessTokenProvider:

BaseBearerTokenAuthenticationProvider screenshot

With these 2 custom classes, we can already do the job. The following snippet is getting an SPFx AadTokenProvider from the AadTokenProviderFactory. Then a custom SpfxAadAuthenticationProvider is created (passing that AadTokenProvider and the Azure AD App ID URI), and that Auth provider is passed to the Kiota FetchRequestAdapter.

SpfxAadAuthenticationProvider screenshot

Note: To make this work, you must change the 'target' attribute in the tsconfig.json file in the SPFx project. For some backwards compatibility with the old browser, the SPFx yeoman template configures that attribute to 'es5', while the Kiota packages require an 'es6' value.

SPFx yeamon template es5 screenshot

Breaking news

We love community. So, while finding a solution and coding our custom Kiota providers for SharePoint framework, we asked ourselves whether this Kiota SharePoint framework Auth provider would be of any interest for anyone else? That answer was ‘yes!’

So we got in touch with some of the Microsoft Kiota PMs, and we sent a Pull request to the official MS Kiota Typescript repository in GitHub. After some reviews and small changes, the contribution is already available in the official repository and you can install it as any other NPM package.

Give it a try and let us know how it goes.

More about Kiota

For more information about Kiota read my previous blog

Author bio

Luis Mañez

Luis Mañez

Microsoft 365 Development MVP | SharePoint and Cloud Solutions architect.  I help find the best technical designs to meet client needs and act as tech lead to build great solutions. I have fun with some R&D tasks, always trying to improve our tools and processes, and I often help the Microsoft community as a blogger and speaker, contributing to open-source projects.

View all articles by this author