Comment créer des webhooks Microsoft Graph fiables pour SharePoint et Microsoft 365
By Mirko Peters ·
Créez des webhooks Microsoft Graph fiables pour SharePoint et Microsoft 365, avec une validation sécurisée, un renouvellement automatisé et une remise des notifications robuste.
Automatically translated with AI from the original post. Read the English original
Créer des webhooks Microsoft Graph fiables pour SharePoint et Microsoft 365 peut mettre à l’épreuve même des développeurs expérimentés. Vous pouvez rencontrer des échecs de validation si votre point de terminaison ne renvoie pas le jeton de validation ou ne répond pas avec un statut 200 OK. Les problèmes courants incluent des points de terminaison bloqués par des pare-feu, des erreurs de configuration réseau ou des interférences de middleware. Les tentatives manquées et les abonnements expirés surviennent souvent lorsque le service ne reçoit pas la requête de validation ou lorsque les points de terminaison ne sont pas accessibles publiquement. Vous découvrirez comment éviter ces écueils et mettre en place un pipeline de notifications robuste et sécurisé, accompagné d’une liste de contrôle pratique et de bonnes pratiques.
Points clés
Les webhooks Microsoft Graph fournissent des notifications en temps réel sur les modifications survenant dans Microsoft 365, ce qui évite d’interroger en permanence le service.
Assurez-vous que votre point de terminaison webhook est accessible publiquement et utilise HTTPS pour garantir la sécurité et la fiabilité.
Répondez rapidement aux demandes de validation en renvoyant le jeton de validation afin d’activer correctement votre abonnement webhook.
Mettez en œuvre une stratégie robuste de nouvelles tentatives et de temporisation (backoff) pour gérer les échecs de remise des notifications et éviter toute perte de données.
Automatisez le renouvellement des abonnements et surveillez votre pipeline de webhooks pour garantir des notifications continues et fiables.
Fondamentaux des webhooks Microsoft Graph
Qu’est-ce que les webhooks Microsoft Graph
Un webhook est une requête HTTP, déclenchée par un événement survenu dans un système source et envoyée à un système de destination, généralement accompagnée d’une charge utile de données. Les webhooks sont automatisés : autrement dit, ils sont envoyés automatiquement dès que leur événement se produit dans le système source.
Vous utilisez les webhooks Microsoft Graph pour recevoir des notifications en temps réel sur les modifications survenant dans votre environnement Microsoft 365. Vous n’avez donc pas besoin d’interroger en permanence Microsoft Graph pour obtenir des mises à jour. Votre application est informée dès que un événement important se produit. Vous restez ainsi à jour et synchronisé avec les données accessibles via Microsoft Graph. Cela supprime également le besoin d’une infrastructure d’interrogation (polling), qui consiste à envoyer fréquemment des requêtes à Microsoft Graph pour vérifier les dernières modifications.
Vous pouvez configurer des notifications pour de nombreux types d’événements, par exemple :
Messages
Événements
Contacts
Utilisateurs
Groupes
Conversations
Fichiers OneDrive
Alertes
Par exemple, vous pouvez vouloir créer automatiquement un compte dans un système tiers de suivi du temps lorsqu’un nouvel utilisateur rejoint votre organisation. Vous pourriez aussi déclencher le traitement de contenu, comme une note de frais, lorsqu’un utilisateur ajoute un nouveau fichier à une bibliothèque de documents SharePoint ou à un dossier OneDrive.
Pourquoi la fiabilité est essentielle
Les webhooks Microsoft Graph jouent un rôle clé pour que vos intégrations SharePoint et Microsoft 365 restent réactives et à jour. Lorsque votre pipeline de webhooks fonctionne de manière fiable, vos applications réagissent aux modifications en temps réel. Les utilisateurs voient toujours les données les plus récentes, ce qui améliore leur expérience et réduit le risque d’informations obsolètes.
Toutefois, les problèmes de fiabilité peuvent entraîner de sérieux désagréments :
Les échecs de webhooks peuvent compromettre le fonctionnement des applications s’ils ne sont pas traités correctement.
Les pics soudains de trafic peuvent saturer les serveurs, entraînant des interruptions de service et la perte de requêtes webhook.
L’absence de traitement des webhooks peut entraîner une perte de données et des incohérences en l’absence de mécanisme de retransmission.
Les URL de webhooks non sécurisées peuvent être exploitées, permettant à des attaquants d’envoyer des données corrompues.
Pour construire une solution robuste, vous devez combiner les webhooks avec les requêtes delta afin de suivre les modifications efficacement. Vous devez également mettre en place des processus pour vérifier et renouveler régulièrement les abonnements. Pour les ressources mises à jour fréquemment, le regroupement des requêtes permet de maîtriser la charge.
Configuration et validation des webhooks
La configuration des webhooks Microsoft Graph pour SharePoint et Microsoft 365 comporte plusieurs étapes importantes. Vous devez enregistrer votre webhook, gérer les requêtes de validation et sécuriser votre point de terminaison. Chacune de ces étapes joue un rôle essentiel pour garantir la fiabilité et la sécurité de votre chaîne de notifications.
Enregistrement des webhooks Microsoft Graph
Commencez par créer un abonnement webhook. Ce processus permet à votre application de recevoir des notifications concernant les modifications apportées aux ressources Microsoft 365. Suivez ces étapes pour enregistrer votre webhook :
Créez un point de terminaison accessible publiquement qui utilise HTTPS. Ce point de terminaison recevra les notifications de Microsoft Graph.
Envoyez une requête POST au point de terminaison
/subscriptionsde Microsoft Graph.Dans votre requête d’abonnement, indiquez :
changeType: les types de modifications à suivre, comme « created », « updated » ou « deleted ».notificationUrl: l’URL de votre point de terminaison webhook.resource: la ressource à surveiller, comme « /users » ou « /drive/root ».expirationDateTime: la date et l’heure d’expiration de l’abonnement.Les propriétés facultatives, comme
clientState, vous aident à vérifier l’origine des notifications.
Exemple de requête d’abonnement :
POST https://graph.microsoft.com/v1.0/subscriptions Authorization: bearer eyJ0eXAiOiJ[..] Content-Type: application/json { "changeType": "updated", "clientState": "SecretClientState", "notificationUrl": "https://yourdomain.com/api/notifications", "resource": "/users", "expirationDateTime": "2024-05-01T00:00:00.0000000+00:00" }
Vous devez vous assurer que votre point de terminaison est accessible publiquement et sécurisé par HTTPS. Microsoft Graph valide l’URL de notification avant de finaliser l’abonnement. Vous devez renouveler les abonnements régulièrement pour continuer à recevoir des notifications. Votre point de terminaison doit fournir des réponses HTTP rapides et cohérentes afin de ne pas manquer de notifications.
Voici un récapitulatif des champs requis pour l’enregistrement :
Champ | Description |
|---|---|
changeType | Indique le type de modification qui déclenche la notification (par exemple, « updated »). |
clientState | Une chaîne personnalisée qui permet de valider l’origine de la notification. |
notificationUrl | Le point de terminaison vers lequel les notifications seront envoyées. |
resource | La ressource surveillée (par exemple, « /users »). |
expirationDateTime | La date et l’heure d’expiration de l’abonnement. |
validationToken | Un jeton qui doit être renvoyé dans la réponse pour valider la requête d’abonnement. |
Gestion des requêtes de validation
Une fois votre webhook enregistré, Microsoft Graph envoie une requête de validation à votre point de terminaison. Vous devez y répondre correctement pour finaliser le processus d’abonnement. Lorsque votre point de terminaison reçoit une requête GET avec le paramètre de requête validationToken, vous devez renvoyer cette valeur telle quelle, en texte brut, dans le corps de la réponse, avec le statut 200 OK.
Type de requête | URL | Paramètre de requête | Content-Type | Corps de la réponse | |
|---|---|---|---|---|---|
GET | validationToken=1234 | 200 OK | text/plain | 1234 |
Si vous ne renvoyez pas le validationToken, une erreur de validation se produit. Microsoft Graph ne peut alors pas confirmer votre point de terminaison, et vous ne recevrez aucune notification.
Vous devez utiliser la propriété clientState pour vérifier que les requêtes proviennent bien de votre abonnement.
Renvoyez toujours le validationToken dans le corps de la réponse, en texte brut, dans un délai de 10 secondes.
💡 Astuce : répondre rapidement et correctement aux requêtes de validation garantit l’activation de votre abonnement webhook sans incident.
HTTPS et sécurité du point de terminaison
La sécurisation de votre point de terminaison webhook est indispensable. Les webhooks Microsoft Graph exigent un chiffrement HTTPS pour protéger les données sensibles pendant les échanges. Vous devez vérifier les requêtes entrantes en contrôlant la signature créée avec une clé secrète partagée. Utilisez des chemins complexes et générés aléatoirement pour vos URL de rappel afin de les rendre plus difficiles à deviner.
Ajoutez une liste d’adresses IP autorisées pour les points de terminaison de l’API Microsoft Graph.
Incluez les jetons d’authentification dans les en-têtes de requête.
Surveillez l’utilisation de vos API afin de détecter les comportements inhabituels ou les pics d’activité.
Restreignez l’accès à Microsoft Graph et aux API Outlook. Seul le personnel autorisé doit y accéder, et vous devez imposer l’authentification multifactorielle.
Déployez des solutions avancées de sécurité des terminaux qui utilisent l’analyse comportementale et l’apprentissage automatique pour identifier les menaces.
Réalisez régulièrement des audits de sécurité afin de détecter et de corriger les vulnérabilités.
Chaque rappel de webhook utilise un JSON Web Token (JWT) signé, placé dans l’en-tête Authentication de la requête HTTPS entrante. Vous pouvez appliquer les techniques standard de validation des JWT OpenID Connect pour garantir l’intégrité du jeton.
Vous devez utiliser HTTPS pour tous les points de terminaison de webhook. Cette exigence protège vos données et garantit la conformité aux normes de sécurité de Microsoft. Sécuriser votre point de terminaison permet de prévenir les accès non autorisés et les attaques.
En suivant ces étapes, vous mettez en place un pipeline Microsoft Graph Webhooks fiable et sécurisé pour SharePoint et M365. Votre application reçoit ainsi les notifications rapidement et en toute sécurité.
Traitement et sécurisation des notifications
Une fois votre point de terminaison de webhook configuré, vous devez traiter les notifications entrantes de manière sûre et fiable. Cette étape garantit que votre application n’accepte que les requêtes valides et que vous ne manquez jamais de mises à jour importantes provenant de Microsoft Graph Webhooks.
Authentification et vérification des jetons JWT
Chaque notification de Microsoft Graph inclut un JSON Web Token (JWT) dans l’en-tête Authorization. Vous devez vérifier ce jeton avant de traiter toute charge utile. Une validation rigoureuse des JWT protège votre système contre les requêtes non autorisées ou altérées.
Suivez ces étapes pour authentifier et vérifier les jetons JWT :
Vérifiez que le jeton n’a pas expiré. Les jetons comportent une heure d’expiration, et vous devez rejeter tout jeton dont la validité est dépassée.
Confirmez que le jeton a été émis par la plateforme d’identité Microsoft. Validez la signature du jeton pour vous assurer qu’il n’a pas été modifié.
Vérifiez que la revendication « audience » du jeton correspond à l’ID de votre application. Cette étape confirme que le jeton était destiné à votre application.
Vérifiez que la propriété
azp(authorized party) correspond à la valeur attendue pour votre application.
Conseil : utilisez toujours des bibliothèques fiables pour la validation des JWT. Elles vous aident à éviter les erreurs courantes et à maintenir la sécurité de votre application.
Soyez également attentif aux vulnérabilités de sécurité courantes lors de la manipulation des jetons JWT :
Ne pas vérifier la signature du JWT peut permettre à des attaquants de modifier le contenu du jeton sans être détectés.
Utiliser l’algorithme « none » dans le traitement des JWT permet aux attaquants de contourner les contrôles de signature.
Des secrets de signature faibles facilitent la falsification de jetons valides par des attaquants.
Des attaquants peuvent injecter des paramètres spécifiques dans l’en-tête JOSE pour manipuler la façon dont votre système traite les JWT.
En suivant ces étapes et ces précautions, vous vous assurez que seules les notifications légitimes atteignent votre application.
Traitement des charges utiles de notification
Après avoir authentifié la notification, vous devez traiter la charge utile de manière sûre. Les charges utiles de notification contiennent des informations sur l’événement qui a déclenché le webhook. Pour préserver l’intégrité des données et prévenir les problèmes de sécurité, vous devez :
Vérifier que tous les champs obligatoires sont présents dans la charge utile. Des champs manquants peuvent provoquer des erreurs ou un traitement incomplet.
Assainissez tous les champs de texte avant de les afficher ou de les stocker dans votre base de données. Cette étape prévient les attaques par injection et la corruption des données.
Utilisez la validation de schéma pour confirmer que la charge utile respecte la structure attendue. La validation de schéma vous aide à détecter les modifications inattendues ou les données mal formées.
Préparez votre code à d’éventuelles évolutions de version de l’API. Un analyseur flexible garantit que votre application continue de fonctionner même si Microsoft modifie le format de la charge utile.
Remarque : la validation et l’assainissement des charges utiles protègent votre système contre les données mal formées et les menaces de sécurité.
Mise en œuvre de la logique de nouvelle tentative et de temporisation
Des problèmes réseau ou des interruptions temporaires peuvent faire échouer la remise des notifications. Pour éviter toute perte de données, vous avez besoin d’une stratégie robuste de nouvelles tentatives et de temporisation. Microsoft recommande d’utiliser une temporisation exponentielle et des files d’attente structurées pour gérer les nouvelles tentatives.
Voici un tableau récapitulant les mécanismes courants de nouvelle tentative et de temporisation :
Type de mécanisme | Description |
|---|---|
Temporisation exponentielle | Augmente exponentiellement le délai d’attente entre les nouvelles tentatives après chaque échec. |
File d’attente principale | La file d’attente initiale dans laquelle les événements webhook sont publiés, par exemple |
Files d’attente de nouvelle tentative | Files d’attente destinées à la gestion des nouvelles tentatives, nommées |
File d’attente d’abandon | Une file d’attente finale destinée aux messages en échec après l’ensemble des tentatives, par exemple |
Calcul du TTL | La durée de vie (TTL, time-to-live) de chaque file d’attente de nouvelle tentative est calculée à l’aide de la formule : |
En-tête x-retry | En-tête qui suit le nombre de tentatives de nouvel envoi pour chaque message. |
Dead Letter Exchange | Un échangeur qui reçoit les messages ne pouvant plus faire l’objet de nouvelles tentatives et les achemine vers la file d’attente d’abandon. |
Si vous ne mettez pas en place une logique appropriée de nouvelles tentatives et de temporisation progressive (backoff), votre application risque de perdre des notifications ou de générer des incohérences de données. Les requêtes en échec ou la limitation de débit peuvent vous empêcher de recevoir des mises à jour critiques. La temporisation exponentielle vous aide à gérer les requêtes limitées et réduit le risque de surcharger votre système ou Microsoft Graph Webhooks.
🛡️ Bonne pratique : suivez systématiquement le nombre de tentatives et déplacez les messages en échec vers une file d’attente d’abandon après plusieurs nouvelles tentatives. Cette approche vous permet d’analyser et de résoudre les problèmes persistants sans perdre de données.
En authentifiant les jetons JWT, en validant les charges utiles et en mettant en œuvre une logique de nouvelles tentatives fiable, vous créez un pipeline de notifications sécurisé et résilient. Ces étapes vous permettent de traiter en toute sécurité et efficacement chaque notification de Microsoft Graph Webhooks.
Gestion des abonnements et suivi des modifications
Automatisation du renouvellement des abonnements
Vous devez maintenir vos abonnements webhook actifs afin de ne manquer aucune notification. Les abonnements Microsoft Graph expirent au bout d’une période définie. Si vous ne les renouvelez pas, votre application cesse de recevoir des mises à jour. Vous pouvez automatiser le renouvellement à l’aide de plusieurs méthodes :
Envoyez des requêtes HTTP PATCH pour mettre à jour la date d’expiration de chaque abonnement.
Planifiez l’exécution quotidienne de ces requêtes PATCH. Vous maintenez ainsi vos abonnements à jour et évitez une expiration inattendue.
Suivez l’horodatage d’expiration de chaque abonnement. Renouvelez tout abonnement proche de l’expiration.
Si un abonnement expire, créez-en immédiatement un nouveau afin de rétablir le flux de notifications.
Conseil : l’automatisation des renouvellements réduit le travail manuel et garantit que votre système reste connecté à Microsoft Graph.
Supervision et alertes
Vous devez surveiller l’état de santé de votre pipeline webhook. Configurez des alertes pour être informé si le renouvellement d’un abonnement échoue ou si votre point de terminaison cesse de répondre. Utilisez la journalisation pour suivre les notifications entrantes et les tentatives de renouvellement. Vous repérez ainsi les problèmes avant qu’ils n’affectent les utilisateurs.
Surveillez l’état des abonnements et les dates d’expiration.
Configurez des alertes en cas d’échec de renouvellement ou de notifications manquées.
Journalisez l’ensemble des événements webhook et des erreurs pour faciliter le dépannage.
🛎️ Une supervision proactive vous permet de résoudre rapidement les problèmes et garantit la fiabilité de votre intégration.
Utilisation des requêtes delta pour le suivi des modifications
Les requêtes delta vous permettent de suivre efficacement les modifications apportées aux ressources SharePoint et Microsoft 365. Vous pouvez les utiliser pour ne recevoir que les données nouvelles ou mises à jour, ce qui réduit le besoin d’interrogations fréquentes et diminue le risque de limitation de débit.
Les requêtes delta permettent à votre application de suivre les modifications sans télécharger l’ensemble des données à chaque fois.
Elles fonctionnent parfaitement avec SharePoint et Microsoft 365 et n’envoient des notifications que lorsqu’une modification intervient.
Les requêtes delta vous permettent d’économiser la bande passante et d’améliorer les performances.
Toutefois, les requêtes delta présentent certaines limites :
Limite/Difficulté | Description |
|---|---|
Contexte OData | Renvoyé de manière incorrecte lors du suivi des modifications apportées aux relations. |
Extensions de schéma | Non renvoyées avec l’instruction $select, mais renvoyées sans elle. |
Extensions ouvertes | Les clients ne peuvent pas suivre les modifications apportées aux extensions ouvertes ou aux extensions de schéma inscrites. |
Remarque : testez systématiquement votre implémentation des requêtes delta afin de prendre en compte ces limites et garantir un suivi précis des modifications.
En automatisant les renouvellements, en supervisant votre pipeline et en utilisant les requêtes delta, vous construisez un système webhook fiable et efficace pour SharePoint et Microsoft 365.
Vous pouvez mettre en place des webhooks Microsoft Graph fiables en suivant une démarche claire. Commencez par créer des abonnements et utiliser des requêtes delta pour suivre les modifications. Automatisez les renouvellements et surveillez votre pipeline pour détecter les anomalies. Privilégiez la validation, la sécurité et la résilience à chaque étape. Pour vérifier que votre solution est prête pour la production, consultez cette liste de contrôle :
Tenez la documentation à jour et informez les équipes de support.
Planifiez des vérifications régulières de l'état des abonnements.
Utilisez des analyses de sécurité du pipeline CI et conservez des pistes d'audit.
Type de mesure | Description |
|---|---|
Analyses de sécurité du pipeline CI | Recherchez les vulnérabilités avant le déploiement. |
Piste d'audit automatisée | Journalisez chaque build et chaque déploiement à des fins de conformité et d'audit. |
Appliquez ces bonnes pratiques pour garantir la fiabilité de vos intégrations SharePoint et Microsoft 365.
Questions fréquentes
Comment renouveler un abonnement webhook Microsoft Graph expiré ?
Envoyez une requête PATCH au point de terminaison Microsoft Graph /subscriptions/{id}. Mettez à jour le champ expirationDateTime. Planifiez l'exécution quotidienne de ce processus. Vos abonnements restent ainsi actifs et vous évitez de manquer des notifications.
Que faire si votre point de terminaison webhook échoue à la validation ?
Vérifiez que votre point de terminaison renvoie le validationToken en texte brut dans le corps de la réponse. Répondez avec un statut 200 OK. Assurez-vous que votre point de terminaison est accessible publiquement et qu'il utilise HTTPS.
Comment sécuriser votre point de terminaison webhook ?
Utilisez HTTPS pour tous les points de terminaison. Validez les jetons JWT dans chaque requête. Restreignez l'accès par authentification et liste blanche d'adresses IP. Surveillez les activités inhabituelles. Auditez régulièrement vos paramètres de sécurité.
Pourquoi utiliser des requêtes delta avec les webhooks ?
Les requêtes delta vous permettent de ne suivre que les données nouvelles ou modifiées. Cela réduit la bande passante et améliore les performances. Vous évitez de télécharger l'intégralité des données à chaque fois, ce qui rend votre intégration plus rapide et plus efficace.
Quelle est la meilleure façon de gérer les notifications webhook en échec ?
Mettez en place une logique de nouvelles tentatives avec un backoff exponentiel. Suivez les tentatives à l'aide d'en-têtes ou de files d'attente. Déplacez les messages en échec après plusieurs nouvelles tentatives vers une file d'abandon. Analysez ces échecs pour éviter toute perte de données.