azure-samples / ms-identity-aspnet-daemon-webapp

A web application that sync's data from the Microsoft Graph using the identity of the application, instead of on behalf of a user.

languages	page_type	description	products	urlFragment
csharp powershell javascript html	sample	Use the Microsoft identity platform endpoint to access the data of Microsoft business customers in a long-running, non-interactive process.	azure azure-active-directory dotnet	build-multi-tenant-daemon-aad

Build a multi-tenant daemon with the Microsoft identity platform endpoint

For a simpler console daemon application, check out the following sample: active-directory-dotnetcore-daemon-v2

We have renamed the default branch to main. To rename your local repo follow the directions here.

About this sample

Overview

This sample application shows how to use the Microsoft identity platform endpoint to access the data of Microsoft business customers in a long-running, non-interactive process. It uses the OAuth2 client credentials grant to acquire an access token, which it then uses to call the Microsoft Graph and access organizational data.

The app is built as an ASP.NET MVC application, and uses the OWIN OpenID Connect middleware to sign in users. Its "daemon" component in this sample is just an API controller, which, when called, pulls in a list of users in customer's Azure AD tenant from Microsoft Graph. This SyncController.cs is triggered by an AJAX call in the web application, and uses the Microsoft Authentication Library (MSAL) for .NET to acquire an access token for Microsoft Graph.

Scenario

Because the app is a multi-tenant app intended for use by any Microsoft business customer, it must provide a way for customers to "sign up" or "connect" the application to their company data. During the connect flow, a company administrator first grants application permissions directly to the app so that it can access company data in a non-interactive fashion, without the presence of a signed-in user. The majority of the logic in this sample shows how to achieve this connect flow using the identity platform admin consent endpoint.

For more information on the concepts used in this sample, be sure to read the identity platform endpoint client credentials protocol documentation.

• Developers who wish to gain good familiarity of programming for Microsoft Graph are advised to go through the An introduction to Microsoft Graph for developers recorded session.

Looking for previous versions of this code sample? Check out the tags on the releases GitHub page.

How to run this sample

To run this sample, you'll need:

• Visual Studio 2017
• An Internet connection
• An Azure Active Directory (Azure AD) tenant. For more information on how to get an Azure AD tenant, see How to get an Azure AD tenant
• One or more user accounts in your Azure AD tenant. This sample will not work with a Microsoft account (formerly Windows Live account). Therefore, if you signed in to the Azure portal with a Microsoft account and have never created a user account in your directory before, you need to do that now.

Step 1: Clone or download this repository

From your shell or command line:

git clone https://github.com/Azure-Samples/active-directory-dotnet-daemon-v2.git

or download and exact the repository .zip file.

Given that the name of the sample is pretty long, and so are the name of the referenced NuGet packages, you might want to clone it in a folder close to the root of your hard drive, to avoid file size limitations on Windows.

Step 2: Register the sample application with your Azure Active Directory tenant

There is one project in this sample. To register it, you can:

• either follow the steps Step 2: Register the sample with your Azure Active Directory tenant and Step 3: Configure the sample to use your Azure AD tenant
• or use PowerShell scripts that:
  • automatically creates the Azure AD applications and related objects (passwords, permissions, dependencies) for you
  • modify the Visual Studio projects' configuration files.

If you want to use this automation:

1. On Windows, run PowerShell and navigate to the root of the cloned directory

2. In PowerShell run:

   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process -Force

3. Run the script to create your Azure AD application and configure the code of the sample application accordingly.

4. In PowerShell run:

   .\AppCreationScripts\Configure.ps1

   Other ways of running the scripts are described in App Creation Scripts

5. Open the Visual Studio solution and click start to run the code.

If you don't want to use this automation, follow the steps below.

Choose the Azure AD tenant where you want to create your applications

As a first step you'll need to:

1. Sign in to the Azure portal using either a work or school account or a personal Microsoft account.
2. If your account is present in more than one Azure AD tenant, select your profile at the top right corner in the menu on top of the page, and then switch directory. Change your portal session to the desired Azure AD tenant.

Register the client app (dotnet-web-daemon-v2)

1. Navigate to the Microsoft identity platform for developers App registrations page.

2. Select New registration.

3. When the Register an application page appears, enter your application's registration information:

   • In the Name section, enter a meaningful application name that will be displayed to users of the app, for example dotnet-web-daemon-v2.
   • In the Supported account types section, select Accounts in any organizational directory.
   • In the Redirect URI (optional) section, select Web in the combo-box and enter the following redirect URIs.
     • https://localhost:44316/
     • https://localhost:44316/Account/GrantPermissions

   Note that if there are more than one redirect URIs, you'd need to add them from the Authentication tab later after the app has been created successfully.

4. Select Register to create the application.

5. On the app Overview page, find the Application (client) ID value and record it for later. You'll need it to configure the Visual Studio configuration file for this project.

6. In the list of pages for the app, select Authentication.

   • In the Advanced settings section set Logout URL to https://localhost:44316/Account/EndSession
   • In the Advanced settings | Implicit grant section, check Access tokens and ID tokens as this sample requires the Implicit grant flow to be enabled to sign-in the user, and call an API.

7. Select Save.

8. From the Certificates & secrets page, in the Client secrets section, choose New client secret:

   • Type a key description (of instance app secret),
   • Select a key duration of either 3 months, 12 months, 18 months, 24 months or Recommended: 6 months.
   • When you press the Add button, the key value will be displayed, copy, and save the value in a safe location.
   • You'll need this key later to configure the project in Visual Studio. This key value will not be displayed again, nor retrievable by any other means, so record it as soon as it is visible from the Azure portal.

9. In the list of pages for the app, select API permissions

   • Click the Add a permission button and then,
   • Ensure that the Microsoft APIs tab is selected
   • In the Commonly used Microsoft APIs section, click on Microsoft Graph
   • In the Application permissions section, ensure that the right permissions are checked: User.Read.All
   • Select the Add permissions button

Step 3: Configure the sample to use your Azure AD tenant

In the steps below, "ClientID" is the same as "Application ID" or "AppId".

Open the solution in Visual Studio to configure the projects

Configure the client project

Note: if you used the setup scripts, the changes below will have been applied for you

1. Open the UserSync\Web.Config file
2. Find the app key ida:ClientId and replace the existing value with the application ID (clientId) of the dotnet-web-daemon-v2 application copied from the Azure portal.
3. Find the app key ida:ClientSecret and replace the existing value with the key you saved during the creation of the dotnet-web-daemon-v2 app, in the Azure portal.

Run the sample

Clean the solution, rebuild the solution, and run UserSync application, and begin by signing in as an administrator in your Azure AD tenant. If you don't have an Azure AD tenant for testing, you can follow these instructions to get one.

When you sign in, the app will first ask you for permission to sign you in & read your user profile. This consent allows the application to ensure that you are a business user.

The application will then try to sync a list of users from your Azure AD tenant, via the Microsoft Graph. If it is unable to do so, it will ask you (the tenant administrator) to connect your tenant to the application.

The application will then ask for permission to read the list of users in your tenant.

You will be signed out from the app after granting permission. This is done to ensure that any existing access tokens for Graph is removed from the token cache. Once you sign in again, the fresh token obtained will have the necessary permissions to make calls to MS Graph. When you grant the permission, the application will then be able to query for users at any point. You can verify this by clicking the Sync Users button on the users page, refreshing the list of users. Try adding or removing a user and re-syncing the list (but note that it only syncs the first page of users!).

Consider taking a moment to share your experience with us.

About the code

The relevant code for this sample is in the following files:

• Initial sign-in: App_Start\Startup.Auth.cs, Controllers\AccountController.cs. In particular, the actions on the controller have an Authorize attribute, which forces the user to sign in. The application uses the authorization code flow to sign in the user.
• Syncing the list of users to the local in-memory store: Controllers\SyncController.cs
• Displaying the list of users from the local in-memory store: Controllers\UserController.cs
• Acquiring permissions from the tenant admin using the admin consent endpoint: Controllers\AccountController.cs

How to recreate this sample

Code for the service

1. In Visual Studio 2017, create a new Visual C# ASP.NET Web Application (.NET Framework) project. In the next screen, choose the MVC project template. Also add folder and core references for Web API as you would be adding a Web API controller later. Leave the project's chosen authentication mode as the default, that is, No Authentication".
2. Select the project in the Solution Explorer window and press the F4 key to bring project properties. In the project properties, set SSL Enabled to be True. Note the SSL URL. You will need it when configuring this application's registration in the Azure portal.
3. Add the following ASP.Net OWIN middleware NuGets: Microsoft.Owin.Security.ActiveDirectory, Microsoft.Owin.Security.Cookies and Microsoft.Owin.Host.SystemWeb, Microsoft.IdentityModel.Protocol.Extensions, Microsoft.Owin.Security.OpenIdConnect and Microsoft.Identity.Client.
4. In the App_Start folder, create a class Startup.Auth.cs.You will need to remove .App_Start from the namespace name. Replace the code for the Startup class with the code from the same file of the sample app. Be sure to take the whole class definition! The definition changes from public class Startup to public partial class Startup
5. In Startup.Auth.cs resolve missing references by adding using statements as suggested by Visual Studio IntelliSense.
6. Right-click on the project, select Add, select "Class", and in the search box enter "OWIN". "OWIN Startup class" will appear as a selection; select it, and name the class Startup.cs.
7. In Startup.cs, replace the code for the Startup class with the code from the same file of the sample app. Again, note the definition changes from public class Startup to public partial class Startup.
8. In the folder, add a new class called MsGraphUser.cs. Replace the implementation with the contents of the file of the same name from the sample.
9. Add a new MVC 5 Controller - Empty called AccountController. Replace the implementation with the contents of the file of the same name from the sample.
10. Add a new MVC 5 Controller - Empty called UserController. Replace the implementation with the contents of the file of the same name from the sample.
11. Add a new Web API 2 Controller - Empty called SyncController. Replace the implementation with the contents of the file of the same name from the sample.
12. For the user interface, in the Views\Account folder, add three Empty (without model) Views named GrantPermissions, Index and UserMismatch and one named Index in the Views\User folder. Replace the implementation with the contents of the file of the same name from the sample.
13. Update the Shared\_Layout.cshtml and Home\Index.cshtml to correctly link the various views together.

How to deploy this sample to Azure

This project has one WebApp / Web API projects. To deploy them to Azure Web Sites, you'll need, for each one, to:

• create an Azure Web Site
• publish the Web App / Web APIs to the web site, and
• update its client(s) to call the web site instead of IIS Express.

Create and publish the dotnet-web-daemon-v2 to an Azure Web Site

1. Sign in to the Azure portal.
2. Click Create a resource in the top left-hand corner, select Web --> Web App, and give your web site a name, for example, dotnet-web-daemon-v2-contoso.azurewebsites.net.
3. Thereafter select the Subscription, Resource Group, App service plan and Location. OS will be Windows and Publish will be Code.
4. Click Create and wait for the App Service to be created.
5. Once you get the Deployment succeeded notification, then click on Go to resource to navigate to the newly created App service.
6. Once the web site is created, locate it it in the Dashboard and click it to open App Services Overview screen.
7. From the Overview tab of the App Service, download the publish profile by clicking the Get publish profile link and save it. Other deployment mechanisms, such as from source control, can also be used.
8. Switch to Visual Studio and go to the dotnet-web-daemon-v2 project. Right click on the project in the Solution Explorer and select Publish. Click Import Profile on the bottom bar, and import the publish profile that you downloaded earlier.
9. Click on Configure and in the Connection tab, update the Destination URL so that it is a https in the home page URL, for example https://dotnet-web-daemon-v2-contoso.azurewebsites.net. Click Next.
10. On the Settings tab, make sure Enable Organizational Authentication is NOT selected. Click Save. Click on Publish on the main screen.
11. Visual Studio will publish the project and automatically open a browser to the URL of the project. If you see the default web page of the project, the publication was successful.

Update the Active Directory tenant application registration for dotnet-web-daemon-v2

1. Navigate back to to the Azure portal. In the left-hand navigation pane, select the Azure Active Directory service, and then select App registrations.
2. In the resultant screen, select the dotnet-web-daemon-v2 application.
3. In the Authentication | page for your application, update the Logout URL fields with the address of your service, for example https://dotnet-web-daemon-v2-contoso.azurewebsites.net
4. From the Branding menu, update the Home page URL, to the address of your service, for example https://dotnet-web-daemon-v2-contoso.azurewebsites.net. Save the configuration.
5. Add the same URL in the list of values of the Authentication -> Redirect URIs menu. If you have multiple redirect URLs, make sure that there a new entry using the App service's URI for each redirect URL.

Troubleshooting

If you get an HTTP 403, even after admin consent, you might have chosen Delegated permissions for User.Read.All instead of Application permissions.

Community Help and Support

Use Stack Overflow to get support from the community. Ask your questions on Stack Overflow first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [adal msal dotnet].

If you find and bug in the sample, please raise the issue on GitHub Issues.

If you find a bug in msal.Net, please raise the issue on MSAL.NET GitHub Issues.

To provide a recommendation, visit the following User Voice page.

Contributing

If you'd like to contribute to this sample, see CONTRIBUTING.MD.

This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

More information

For more information, see MSAL.NET's conceptual documentation:

• Tenancy in Azure Active Directory
• Understanding Azure AD application consent experiences
• How to: Sign in any Azure Active Directory user using the multi-tenant application pattern
• Understand user and admin consent
• Application and service principal objects in Azure Active Directory
• Quickstart: Register an application with the Microsoft identity platform
• Quickstart: Configure a client application to access web APIs
• Acquiring a token for an application with client credential flows

For more information about the underlying protocol:

• Microsoft identity platform and the OAuth 2.0 client credentials flow

For a simpler multi-tenant console daemon application, see active-directory-dotnetcore-daemon-v2

ms-identity-aspnet-daemon-webapp's Issues

Sample is old and does no build

.net core sample: https://github.com/azure-samples/active-directory-dotnetcore-daemon-v2
It does not make sense for a web app to be a daemon app?
I am not able to build this in VS 2019. ADO pipeline is broken.

Can we deprecate it? @jmprieur

Missing step in registering the App

Hi, all.

There is a missing step in the app registration process. After choosing the "Web" platform one will need to select "Allow Implicit Flow".

Cheers

Graph: Filter Calendar Events by Attendees

when calling "me/events?$filter=attendees/any(a: a/emailAddress/address eq '')"

I get the following error:

{
"error": {
"code": "UnsupportedEntityExpression",
"message": "'i => i.Attendees.Any(a => (a.EmailAddress == ""))' is not a supported filter expression.",
"innerError": {
"request-id": "0f6b84c5-d037-4053-88f2-7df86807d6fd",
"date": "2017-09-29T10:07:28"
}
}
}

does anyone know why?

Graph AD don't find sharepoint sites

Hi everybody

I try to list all my subsites of my organization

when i use : https://graph.windows.net/XXXXX.com/domains, i've got all my domains but not my sharepoint domaine like this one : XXXX.sharepoint.com

so my requestion https://graph.windows.net/sites/XXXX.sharepoint.com give me an invalide domain error

Any help ?

We had trouble sync'ing users, please try again. If problem persists, file an issue on GitHub :)

Getting this message after clicking on "sync users now".
We had trouble sync'ing users, please try again. If problem persists, file an issue on GitHub :)

Graph access always returns 403, even after admin consent

I can't make this sample work.

I followed the configuration steps:

• I added "User.Read.All" Application permission in the app portal
• I replaced value of clientId and clientSecret in App_Start\Startup.Auth.cs

I hit the "Grant Permissions" button, I login with an admin account, I'm redirected back to GrantPermissions in AccountController.cs, the error param is null and admin_consent is "True" and I'm being redirected to /User.
All seems OK.

However, in the UserController Index() action, the GET to "https://graph.microsoft.com/v1.0/users" always returns 403, which redirect me again to the admin consent.

I'm stuck and cannot find what I'm doing wrong.

Any help appreciated.

repeatedly asked to Grant permissions

Followed the step by step guide to the point. Encounter the bug where I am repeatedly asked to grant permissions (403 forbidden response code).

Your guide references to Synccontroller comments for how to solve the issue, but the comments does not explain how to solve the issue, only explains what the issue is.

error while running the application

I get the following error when running

Could not find a part of the path 'D:\Temp\active-directory-v2-master\UserSync\bin\roslyn\csc.exe'.

the example does not work with personal email

Hi,

I am trying to build a daemon service that integrates with outlook 365. I have to use my personal email since my work email does not have admin privileges. However, it seems that the authentication service only work with work and school email right now. It complains that my log in email is not work or school email, even though I have Azure 's subscription (trial) and set up tenant, etc. Is it the current limitation or did I missed any steps?

Thanks,
Huy Vo

Consider writing a daemon example as an actual daemon, not a web application

Why is every Microsoft example of a daemon, non-interactive graph client implemented as a web application? This makes zero sense and only serves to confuse the basic concepts far more than necessary.

Every time I find an example here, it's an MVC app, or a Web API app. This is NOT what the real world wants to see when you talk about daemon sample code. A daemon should be at a minimum implemented as a headless, non-interactive console application. This is then easily shimmed into a Azure Web Job, Azure Function or a Windows Service. Trying to remove the cruft around a web application and get one's head around how admin consent is applied to an app registration destined for a console app is far more muddy than it needs to be.

When using AcquireTokenForClient(), should we use a TokenCache ?

In SyncController.cs, a TokenCache is sent to the ConfidentialClientApplication constructor, but in UserController.cs, null is sent.

I tried using my custom cache, but I see no activity when calling AcquireTokenForClient().

So is a TokenCache relevant when using OAuth2 client credentials grant ?

A company plans to deploy a non-interactive daemon app to their Azure Tenant.

Hello, I want to know about the tenant application which uses it's app service in azure environment.

How to protect web api accessible from multiple daemon apps?

This example is that the SAAS application needs app permissions to multiple tenants. But how to implement the opposite?

1. Have the multiple tenants register their own app registration and validate that on the web api?
2. Register multiple client certificates/ secrets on 1 app registration on the SAAS app?
3. Register multiple app registration with their own client certificate/ secret, however the web api does need to understand multiple client id's.
4. Use own key+secret pair, not using tokens (I guess most of the time implemented as it is quite straight forward, but maybe less secure).

I guess only scenario 2 or 4 is possible. It will give 5000 client secrets for 5000 daemon apps. Is there a limit on the number of secrets?

Sample requires installation of .NET Framework devpack 4.6.1 (not supported) and throws exception on launch.

Visual Studio 2022 displays a modal when you first open the UserSync solution asking if you want to update the code to the latest framework or launch a browser to download the 4.6.1 framework. If you launch the browser, .NET Framework 4.6.1 does not show in the "supported" list. You can do it by changing the URL for 4.6.2, the supported version.

After installing 4.6.1 and relaunching Visual Studio, there is no modal.

After build and Run, I get the following exception immediately on launch:
"Could not load file or assembly 'Microsoft.Owin, Version=4.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

Great sample, but hard to follow

I have successfully made the sample working from the provided description and I see this project is also referenced in many other cases.

But there are several greater issues at hand.

1. I think the MVC model sample is lacking comments and versatility.
2. A clear flow of operation is hard to follow due to "magic" and unexplained middle-ware handling and a tight coupling with the OWIN architecture. Keep in mind, there are developers in dire need of replacing their former EWS (Exchange Web Service) authentication due to end-of-life at 13. Oct 2020.
3. the sample doesn't distinguish clearly between authentication of the user and the daemon access grants - there is an overlap between the tenant provided by the login-user and the admin-account needed to grant access to the AD users. A stack-exchange post helped me to solve how to provide the tenant ID for an Exchange domain (Try access https://login.microsoftonline.com/{domain}/.well-known/openid-configuration ), but let's say I just need the grant from within a standard webforms application? This project is heavily relying on the OMC framework and therefor hardly serves as a clear daemon app example for thousands of developers out there?

Sample of exposing own secured api and calling via daemon app on its own name

There is an example of exposing own api and consuming via daemon app for .net core but not for asp.net
a sample for same would be great.
.Net core sample can be found here.
https://github.com/azure-samples/active-directory-dotnetcore-daemon-v2

Lot of errors

Hi,

I followed the exact steps. I havent touched the code except for client id and app secret. But the build isnt happening because of the errors. Is there something i should install or any packages to be added?

Here are the errors i am getting

Severity Code Description Project File Line Suppression State
Error CS0234 The type or namespace name 'Identity' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Controllers\AccountController.cs 25 Active
Error CS0246 The type or namespace name 'ITokenCache' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALAppTokenMemoryCache.cs 42 Active
Error CS0246 The type or namespace name 'TokenCacheNotificationArgs' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALAppTokenMemoryCache.cs 59 Active
Error CS0246 The type or namespace name 'TokenCacheNotificationArgs' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALAppTokenMemoryCache.cs 72 Active
Error CS0246 The type or namespace name 'ITokenCache' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALUserTokenMemoryCache.cs 42 Active
Error CS0246 The type or namespace name 'TokenCacheNotificationArgs' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALUserTokenMemoryCache.cs 50 Active
Error CS0246 The type or namespace name 'TokenCacheNotificationArgs' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALUserTokenMemoryCache.cs 60 Active
Error CS0246 The type or namespace name 'TokenCacheNotificationArgs' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALUserTokenMemoryCache.cs 71 Active
Error CS0246 The type or namespace name 'TokenCacheNotificationArgs' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Utils\MSALUserTokenMemoryCache.cs 80 Active
Error CS0234 The type or namespace name 'Identity' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Controllers\AccountController.cs 25 Active
Error CS0246 The type or namespace name 'IConfidentialClientApplication' could not be found (are you missing a using directive or an assembly reference?) UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Controllers\AccountController.cs 129 Active
Error CS0103 The name 'ConfidentialClientApplicationBuilder' does not exist in the current context UserSync C:\graph\active-directory-dotnet-daemon-v2\UserSync\Controllers\AccountController.cs 130 Active

Non-expiring secrets not supported any more

In the line 123 of the readme it suggests creating a secret that might not expire - this is not possible as non-expiring secrets were deprecated some time ago...

ms-identity-aspnet-daemon-webapp/README.md

Line 123 in 2515242

- Select a key duration of either **In 1 year**, **In 2 years**, or **Never Expires**.

Can token caching be simplified to singleton dependency injection?

The part of this sample which showcases a client-credential flow whereby the Sync Controller fetches a token, leverages a custom cache implementation. (A "cache of the cache" as a matter of speaking.) This is done by wrapping the MSAL token cache in another custom cache implementation called "MSALAppTokenMemoryCache".

This seems overly complex for the scenario at hand. (There is no need for a redirect url in a client cred flow, so we have all information at hand to construct the IConfidentialClientApplication on beforehand.)

Can we instead simplify this and construct the IConfidentialClientApplication just once at startup and from there, inject it into the controller as a singleton dependency? This would allow to leverage the MSAL built-in token cache directly without the need for a custom implementation.

This would require the call to "AcquireTokenForClient" to be thread safe though; which is not something which is explicitly documented.

Thanks for your help in shaping clarity around this. /cc @jmprieur