Integrate a chat bot in SharePoint portal using an SPFx extension, MSAL, LUIS and the Bot Framework

Integrate a chat bot in SharePoint portal using an SPFx extension, MSAL, LUIS and the Bot Framework

With the democratization of AI, integrate chat bots inside SharePoint portals may be more and more common in the near future. According to this trend, I wanted to explore this specific usage and especially the authentication mechanisms allowing deep integration in SharePoint based intranet solutions. Actually, to be truly efficient, a bot must propose personalized answers to the users by calling protected APIs like Microsoft Graph or custom APIs and it is precisely the pupose of this sample. The complete code, deployment and debuging instructions are available in the PnP repository here if you want to try this out:

Basically, this solution shows how to integrate a bot web chat (the React web chat component) inside a modern SharePoint site using an SPFx extension, the MSAL library and the Bot Framework. User intents are determined by a LUIS model and mapped to specific Microsoft graph queries in the bot logic. This is obviously a dummy example and in a real world scenario, you may want to use more complex dialogs/queries to help your users but the concept is still valid.

Create chat bots consuming Azure AD protected APIs

The main problematic: Let’s say you want to integrate a bot in your SharePoint portal. Depending of what you’re trying to achieve, you will probably need to call protected back-end APIs to retrieve relevant data. I’ve listed here multiple solutions that can be used to implement such a scenario in a chat bot context:




The lazy way

Use application permissions instead delegated permissions in the Azure AD application. In this case, you don’t care about the user permissions since your application will use its own predefined permissions to perform queries.

  • Fairly easy to implement

  • Since you don’t care about the talking user, this solution is only suitable for very few cases (like administration automation operations). Otherwise, this solution can present obvious security risks.

The easy way

Use the bot back channel and perform queries in the SPFx code (or client side code in general), not in the bot itself. This is basically the approach shown in this article. In this kind of solution, your bot does not call any protected APIs. Instead, it uses the Bot Framework back channel mechanism to simply notify the client side code what queries to execute according to the user intents. Since SPFx provides an GraphHttpClient with seamless authentication, you don’t need to handle it yourself. In return, the client side code notify the bot through back channel (again) with the query result so they can be displayed in the chat window.

Existing resources

  • Fairly easy to implement
  • Seamless user experience
  • No need to handle then authentication flow since SPFx does it for you.

  • Very specific to the client side code capabilities. Here SPFx and the GraphHttpClient.
  • Can’t use other APIs other than Graph or SharePoint APIs in this case (i.e. no custom business API).
  • A lot of information exchanged through the back channel that could impact performances.

The “by the book” way

OAuth 2 implicit grant flow

(this sample)

Implement the OAuth2 implicit grant flow to perform queries under the current user identity using his permissions. In this scenario the authentication flow is handled by specialized libraries like MSAL (Azure AD v2) or ADAL (Azure AD v1). The access token is passed through the back channel from the client side code to the bot. Then queries are performed in the bot code using this token.

  • Can be used with any Azure AD protected APIs, not only Microsoft Graph.
  • Standard and supported implementation using official MSAL library (or ADAL for Azure AD v1)

  • Can be used with only the web chat channel.
  • Need the user to authenticate (on single click) at least one time.

The “by the book” way

OAuth2 authorization flow

Implement the OAuth2 authorization code flow to perform queries under the current user identity using his permission. In this scenario, the authentication flow is handled by the bot itself. A sign-in link is generated and displayed in the channel interface (can be a web chat, Teams, Skype, etc…) redirecting the user to its login page. Once logged, the bot handles access token retrieval and use it to perform queries.

Existing resources

  • Can be used with multiple channels (Web chat, Teams, Skype, etc.)
  • Standard and supported implementation

  • More complex implementation than other solutions.
  • User needs to sign-in in an external window.

Quick words on the MSAL library usage with SharePoint and SPFx

In this sample, I chose the MSAL option instead of ADAL since it targets the Azure AD v2 endpoint. Actually, using either option will give the same results in this sample, but since Microsoft moves to MSAL, I decided to try it out starting from the PnP react-msal-msgraph sample. The MSAL library for JavaScript is available here: The main difference between v1 and v2 is in v2, you can now define dynamic permissions through the “scope” parameter.

In this way, you don’t have to specify permissions directly in your app anymore. This approach gives you more flexibility in your implementation. However, using this library presents some caveats (as of 30/12/2017) listed as follows:

  • No Single-Sign-On. You will always see the login popup for the first time even if you are already connected. Unfortunately, this behaviour is hard coded in the library via the “prompt=select_account” query parameter (see this StackOverflow thread for more information). To get a SSO like, you will have to use, for now, ADAL.js instead. A good starting point on how to use it with SPFx can be found in the react-aad-implicitflow PnP Sample.
  • To be generic, you will have no choice to use an SPFx extension. I explain: actually, to get the authentication works properly with the MSAL library, you will need to respect at least two constraints:

The redirect URI you specify in the client-side code must match the one set in the Azure AD application (an error will be raised otherwise). To use the MSAL library, your code must instantiate an UserAgentApplication object as follows:

You have the choice here to set your own redirect URI. If you don’t specify any value, the current URL will be taken. In this case, it means you will need to add a redirect URL in your AAD app for every page in your portal where this code is used to respect this constraint. Not very convenient in a real world scenario…

For the login popup window to close, the page pointed by the redirect URL in your Azure AD application must have an instance of UserApplicationAgent. It means you need a custom component in that specific page. It can be a Web Part, a JavaScript snippet or, more appropriated, an SPFx extension (of ApplicationCustomizer type). For information, this behaviour is not an issue and it’s by design see I take this opportunity to mention the PnP react-msal-msgraph sample will only work in your workbench page for this reason.

The solution I found to respect these two constraints and still be generic is to set the site collection root URL as a redirect URI, both in the UserAgentApplication object and in the Azure AD application:

Although it works, this behaviour can be very misleading because it means the redirect URl won’t be the final URL where the token is transmitted. This URL is only here to actually close the popup window…

Bot state and conversation history

Once logged, the access token is sent to the bot using the Bot Framework back channel via the “userAuthenticated” event and using the user mail as unique identifier to get corresponding data afterwards:

Client side code (SPFx extension)

Server side code (bot)

Then, it is saved in the private conversation data structure in the bot storage context. By this way, we are able to reuse it in queries during dialogs via the session object:

In this sample and for development purpose, I used the “In-memory” bot storage (the data is cleared each time the bot is restarted). However, it is possible to use an Azure Table, CosmosDb or SQL Azure to store your information in a production scenario.

Also to keep conversation history, I store its id in the browser local storage using PnP utilities (15 minutes expiration). I use local storage instead session storage simply to be able to keep the conversation in multiple tabs (not possible with session storage). If you don’t do that, a new conversation will be created every time and previous data will be lost (not really in the back end, but for the user, yes). It can be frustrating so keeping the history is a crucial point:

Hope this quick sample can help you to create awesome chat bot solutions!


Add yours
  1. Luana Fernandes

    Thank you very much for this. I am trying to figure out a way of not having to sign in if my bot is already in SharePoint as a web part. Do you have anything that goes through this? Thank you very much!

    • Franck Cornu

      Hi Luana, you can use SPFx 1.6.0 with the AADTokenProvider utility class for this scenario. Just pass the access token to the bot directly. You can replace the login part by the token retrieval process.

  2. Kasun Perera

    Hi Franck, is it possible to store the direct line secret on the server side of sharepoint and have a controller similar to MVC to generate a token using the secret on the server side send token+conversation id of the user to the client?

    • Franck Cornu

      Hi Kasun. Not sure to fully understand but since it designed for SharePoint Online, you can’t access the SharePoint ‘server’. Storing the direct line secret + other information in the property bag is a convenient way but of course not fully secure. If you want to hide these information from the client, you can still write you own backend service in Azure for instance.

+ Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.