Learnings around developing with Microsoft Graph Toolkit

David Lee

Learnings around developing with Microsoft Graph Toolkit

Note: the picture that illustrates this article has been generated by AI on Bing Image Creator.

Introduction

Recently, we collaborated with a customer to help create a Teams-backed chat experience within their web application, using the Microsoft Graph Toolkit React components. The Microsoft Graph Toolkit (MGT) enables developers to accelerate frontend development when working with Microsoft Graph APIs. The purpose of this blog is to help developers get started with Microsoft Graph Toolkit effectively from our learnings which includes data leaking and privacy concerns.

Developing with your own sandbox Entra Tenant

For development and testing purposes, it is useful for each developer to create their own Entra tenant, backed by M365 developer licensing using the M365 Developer program. The key advantage is that you will have your own sandbox environment that is external to your organization and avoid data segregation and privacy concerns as you work on integrating Microsoft Graph Toolkit components into your application.

As an example, you may have a use-case that require access to Teams chat messages of other Teams users. If you are using your own sandbox environment, then this is no longer a privacy concern given all users are from the sample dataset managed by you. In addition, by having your own Entra tenant, you will also have full administrative rights to provision and maintain any app registrations. Your organization may have additional controls around app registration provisioning which can complicate and delay development efforts. Lastly, you now have full rights to experiment with the user consent process so that you can provide the right experience for your end users without impacting your organizational tenant.

However, you should take note of the following considerations:

• There is a renewal period for the M365 Developer program which expires every 90 days. The renewal process is automatic but should be something you take note of in case it expires. This can happen due to inactivity or other reasons.
• There is a limit to the number of licensed users that is currently set at 25 users. This limit includes your own user account. If you are looking to test for more than 25 licensed users in a single tenant, you will need to consider other options.
• Unless your sandbox Entra Tenant is associated with an Azure Subscription (for billing purposes), you will not be able to test out components that support a Payment model where it is enabled.
• You are on the hook for maintaining the security of your Entra tenant and you should follow best practices.

Evaluation Mode

If you are using a component that leverages an API or Subscription that has payment or licensing requirements, you should note that the component would likely default to Evaluation Mode. With Evaluation Mode, there is a limit for the usage of the API or subscription and the component can fail silently when the limit is exceeded. This means you may be spending time debugging the issue without realizing this is happening.

As an example, assume you are using a component that leverages the following subscription: /users/{user-id}/chats/getAllMessages. With this subscription, you will receive a message notification when a message is sent to this user via Teams chat. Per current documentation, there is a limit of 500 messages per month per tenant per app. The app is a reference to the clientId you have configured as part of your Msal2Provider configuration. When the limit is exceeded, you will notice that you are no longer receiving Teams chat messages. You do not get any error, just no Teams chat message notification comes through.

The workaround in this case is to create another app registration (clientId) or use an existing app that has not been used before. At the start of a new month, you can go back to using the original app if you so desire. Obviously, this approach is only viable for development. For production, the component should be configured with the appropriate payment model and the app should be configured for payment where applicable.

Multi-account use case

The default configuration for Msal2Provider includes support for multi-account logins. This means there could be more than one user who is signed in. This supports the use case where a user has more than one profile the user would like to use. However, if this use case is not expected, such as on a shared desktop, this could result in a privacy issue. For instance, if a user sharing the desktop fails to sign out while another user using the same browser signs in.

As an example, if you include the Login component, this component allows switching between signed in users and could allow the viewing of data, such as messages, belonging to another user.

If your use case does not expect this, you can configure the isMultiAccountEnabled flag to false to minimize the privacy concern when configuring Msal2Provider.

Providers.globalProvider = new Msal2Provider({
    baseURL: graphEndpoint,
    clientId: clientId,
    scopes: scopes,
    isMultiAccountEnabled: false,
});

Other considerations

• Ensure you review the permissions required by each of the component(s) you are using so that you can configure scopes with the minimum permissions in the Msal2Provider. You should note that consent process may occur outside of the sign-in process if there are missing scopes in Msal2Provider, which is not an ideal user experience.
• For component-related issues, we should note that components will be logging into the browser console, which can include Graph API related specific errors, useful for debugging purposes. One example is Payment model specific errors that can show up in the logs if you did not configure payment setup correctly.
• Some components leverage caching using IndexDb when a user is signed in and clears the cache when the user signs out. It might be useful to review what is cached when a user is signed in to understand if there are any privacy concerns based on your specific use case. Follow the documentation for more details on how to inspect the cache.

Conclusion

We hope this blog post is useful for you as you are working with Microsoft Graph Toolkit. The Microsoft Graph Toolkit is actively being developed and enhanced as evident in the road map. Given that Microsoft Graph Toolkit is an open source project, you are also able to contribute back if you see any gaps in functionality or need to report or fix an issue.

David Lee

Follow