Autorisation Webhook

Introduction

Vérifier la légitimité des requêtes webhook entrantes est crucial pour l’authentification webhook. Ce processus garantit que les requêtes proviennent de sources fiables, protégeant ainsi les applications contre les accès non autorisés et les activités malveillantes. Sans authentification appropriée, les systèmes risquent d’être victimes de violations de données et d’exploitation.

Cette page présente les webhooks et leur fonctionnement. Pour une analyse plus approfondie, veuillez consulter notre Espace développeurs ici.

Qu’est-ce qu’un webhook ?

Un webhook nécessite un expéditeur (configuré pour reconnaître les événements) et un destinataire (une application avec une API). Lorsqu’un événement se produit, l’expéditeur notifie le destinataire. Les webhooks permettent de s’abonner facilement aux réponses aux événements applicatifs.

Les webhooks vous avertissent automatiquement via un événement si de nouvelles informations ou données ont été publiées.

Prenons un exemple courant :

1. Votre vol est retardé.
2. Le webhook est déclenché en raison du retard.
3. Une notification push vous est envoyée pour vous informer du retard.

Types de Webhooks

Dans ce document, nous allons présenter trois exemples d’authentification par Webhook proposés par Esendex Connect. Pour des exemples et des informations plus détaillés, vous pouvez accéder au portail des développeurs ici (ajouter le lien une fois actif).

Attention : Actuellement, vous ne pouvez utiliser qu’une seule méthode d’authentification par Webhook par compte. Si vous essayez d’envoyer des messages avec plusieurs méthodes, vous obtiendrez une erreur indiquant qu’une seule est autorisée.

Authentification de base

Qu’est-ce que l’authentification de base ?

L’authentification de base est une méthode d’authentification HTTP simple qui nécessite la saisie d’un nom d’utilisateur et d’un mot de passe pour accéder à un point de terminaison d’API. Cette approche est couramment utilisée pour sécuriser les API, garantissant que seuls les utilisateurs autorisés peuvent accéder à certaines ressources.

Parcours

• Lors de la configuration de l’authentification de base (Basic Auth) pour un webhook, vous avez la possibilité de fournir soit une combinaison nom d’utilisateur et mot de passe, soit directement le jeton d’authentification (token). Cette flexibilité facilite l’intégration et la gestion des informations d’identification de sécurité.

• Lorsqu’une combinaison nom d’utilisateur et mot de passe est fournie, nous générons un jeton d’authentification en utilisant la méthode de codage base64 (nom d’utilisateur : mot de passe). Cette approche respecte le mécanisme standard utilisé pour l’authentification de base.

• Si l’utilisateur ne respecte pas les consignes de création de jeton, nous proposons une option alternative lui permettant de définir directement le jeton.

Jeton de vérification 0Auth (Jeton Bearer)

Qu’est-ce qu’0Auth ?

Dans Auth0, le processus d’authentification par jeton exige que les utilisateurs confirment leur identité. Après une vérification réussie, Auth0 génère un jeton unique, tel qu’un jeton d’accès. Ce jeton permet aux utilisateurs d’accéder à des ressources sécurisées, éliminant ainsi le besoin de saisir leurs identifiants à plusieurs reprises.

Fonctionnement

• Notre plateforme a besoin d’une autorisation pour envoyer des informations au serveur de notre client. Pour ce faire, nous avons besoin d’une clé spéciale prouvant que nous sommes autorisés à le faire.

• La plateforme du client dispose d’un serveur d’autorisation qui agit comme un gardien et émet des clés d’accès temporaires appelées jetons d’accès (Access Tokens).

• Nous fournissons à notre plateforme un identifiant public afin que le serveur de notre client puisse nous reconnaître. Nous prouvons ensuite l’authenticité de cet identifiant en fournissant un code secret (clientSecurityValue) que seuls nous et le serveur d’autorisation de notre client connaissons.

• Nous indiquons ensuite à notre plateforme où aller pour obtenir un jeton d’accès (tokenUrl) auprès de notre client, ainsi que le code secret qu’elle devra faire correspondre pour franchir le garde-barrière du client (serveur d’autorisation).

• Si le serveur d’autorisation vérifie ces informations et qu’elles sont correctes, il émet un jeton d’accès temporaire à notre plateforme, lui permettant d’envoyer des informations au serveur du client avec un horodatage qui expirera après un certain délai.

• Désormais, lorsque notre plateforme envoie un appel webhook au serveur du client, elle inclut le jeton d’accès comme preuve d’autorisation. Si ce jeton est accepté, les informations sont envoyées avec succès.

• Un nouveau jeton d’accès doit être utilisé pour chaque appel webhook.

En-tête personnalisé (clé API)

Qu’est-ce qu’un en-tête client ?

L’authentification par clé API via un en-tête personnalisé est une méthode qui utilise une clé unique générée par le serveur. Cette clé est incluse par les clients dans un en-tête HTTP personnalisé lors de leurs requêtes d’accès à une API. Cette approche garantit un accès sécurisé en vérifiant l’identité du client à l’origine de la requête.

Parcours

• 1. Clé API : Une clé API est une chaîne secrète qui identifie l’expéditeur du webhook.
  • Nous générons la clé API pour vous (nous nous en chargeons).
  • Votre clé API doit vous être unique. Il est recommandé de générer une nouvelle clé API pour chaque abonnement à un webhook.
  • Votre clé API est une information sensible et sera traitée comme telle.
• 2. En-tête personnalisé : La clé API est envoyée via un en-tête HTTP personnalisé, défini par le consommateur du webhook.
  • Le nom de l’en-tête personnalisé est généralement un identifiant unique, tel que « x-api-key » ou « api-key ».
  • Il est recommandé d’utiliser HTTPS pour la communication webhook afin de sécuriser la clé API et les autres données en transit.

• 3. Requête webhook : Lorsque le webhook est déclenché, son producteur (Esendex Connect) inclut un en-tête personnalisé contenant la clé API dans la requête.
  • Le consommateur webhook doit être configuré pour reconnaître l’en-tête personnalisé et sa clé API associée.
• 4. Authentification : Le consommateur webhook vérifie la présence et la validité de l’en-tête personnalisé contenant la clé API. Si l’en-tête est inclus et que la clé API est correcte, la requête webhook est considérée comme authentique.
  • La clé API doit comporter 32 caractères, être sensible à la casse et être alphanumérique.
• 5. Validation : Le consommateur webhook (l’utilisateur, c’est-à-dire vous) valide la requête webhook à l’aide de la clé API pour décider si elle doit être authentifiée.

Exemple

Supposons que vous disposiez d’une clé API, « MY_ESENDEX_CONNECT_KEY », et que vous souhaitiez l’utiliser dans un en-tête personnalisé appelé « x-my-titan-key ». La requête webhook doit inclure l’en-tête suivant :

x-titan-app-key: ESENDEX_ CONNECT_API_KEY

Le consommateur du webhook doit valider l’existence de cet en-tête et la valeur « MY_ESENDEX_CONNECT_KEY » correspondant à une clé API valide.

Vous pouvez découvrir plus en détail le webhook sur notre portail des développeurs ici.