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:
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:
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.
Now, the getAuthorizationToken, just needs to call the SPFx AadTokenProvider getToken method:
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:
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.
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.
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.
For more information about Kiota read my previous blog