Authentification

Configuration d'Event Bridge prend en charge six types de point de terminaison et sept méthodes d'autorisation, mais toutes les combinaisons ne sont pas valides — les quatre points de terminaison natifs Azure (Service Bus, Event Hub, Queue Storage, Event Grid) n'acceptent chacun que les méthodes d'autorisation qui ont un sens pour cette ressource Azure, et Business Central l'impose : choisir une combinaison non prise en charge dans Setup génère immédiatement une erreur, avant même de pouvoir enregistrer.

Combinaisons prises en charge

Point de terminaison	No Auth	Basic Auth	API Key	OAuth 2.0	Azure SAS Token	Storage SAS Token	Event Grid SAS Token
RabbitMQ	⚠️	✅	❌	✅	❌	❌	❌
API endpoint	⚠️	✅	✅	✅	❌	❌	❌
Azure Service Bus	❌	❌	❌	✅	✅	❌	❌
Azure Event Hub	❌	❌	❌	✅	✅	❌	❌
Azure Queue Storage	❌	❌	❌	✅	❌	✅	❌
Azure Event Grid	❌	❌	✅	✅	❌	❌	✅

✅ pris en charge · ⚠️ pris en charge, mais déconseillé en dehors des tests locaux — voir No Auth · ❌ non pris en charge

Points de terminaison

Les champs de connexion propres à chaque point de terminaison (URL, espace de noms, nom de file d'attente, etc.) sont documentés dans Setup → Endpoint. Cette page traite de la méthode d'autorisation que chacun accepte, et pourquoi.

RabbitMQ

Publie vers un échange RabbitMQ via son API HTTP Management. Accepte No Auth ou Basic Auth — un utilisateur type de l'API Management — ou OAuth 2.0 s'il se trouve derrière un proxy inverse ou une passerelle qui émet des jetons porteurs à la place. API Key et Azure SAS Token ne sont pas proposés : l'API Management de RabbitMQ elle-même n'a aucune notion de l'un ou l'autre, il n'y a donc rien côté récepteur qui les accepterait jamais.

API endpoint

Envoie du JSON brut en POST vers l'URL de votre choix. Accepte No Auth, Basic Auth, API Key, ou OAuth 2.0 — les quatre schémas d'autorisation HTTP à usage général — choisissez donc celui qu'attend votre système récepteur. Les trois méthodes restantes (Azure SAS Token, Storage SAS Token, Event Grid SAS Token) sont des schémas de signature spécifiques à Azure, réservés à leurs propres points de terminaison ; voir ces méthodes ci-dessous pour comprendre pourquoi. Pour un exemple concret, voir Zapier, Make.com & Power Automate.

Azure Service Bus

Publie vers une file d'attente ou un topic Service Bus via son API REST. Azure n'accepte que OAuth 2.0 (une inscription d'application Entra ID) ou un Azure SAS Token (une clé de stratégie d'accès partagé) pour cette API — il n'existe pas de notion de Basic Auth ou de clé API sur Service Bus lui-même, c'est pourquoi Event Bridge bloque les autres méthodes d'autorisation pour ce point de terminaison plutôt que de vous laisser configurer une combinaison qu'Azure rejetterait de toute façon.

Azure Event Hub

Publie vers un Event Hub via la même API REST de messagerie qu'utilise Service Bus — Event Hubs est construit sur ce même protocole, ce qui explique qu'il accepte exactement les deux mêmes méthodes d'autorisation, pour les mêmes raisons : OAuth 2.0 (une inscription d'application Entra ID) ou un Azure SAS Token (une clé de stratégie d'accès partagé, provenant de l'espace de noms Event Hub plutôt que de Service Bus). Aucune notion de Basic Auth ou de clé API ici non plus.

Azure Queue Storage

Publie vers une file d'attente d'un compte de stockage via son API REST. L'API du plan de données d'Azure Storage accepte OAuth 2.0 (une inscription d'application Entra ID avec le rôle Storage Queue Data Message Sender) ou un Storage SAS Token (généré pour cette file d'attente précise) — encore une fois, pas de Basic Auth ni de clé API générique. Azure SAS Token ne s'applique pas non plus ici : les Storage Queues utilisent un jeton SAS de forme différente, ce qui explique qu'il s'agisse d'une méthode d'autorisation distincte de celle de Service Bus/Event Hub.

Azure Event Grid

Publie vers un topic personnalisé Event Grid via son API REST, en enveloppant chaque événement dans le schéma d'événement propre à Event Grid (id, subject, eventType, eventTime, et un objet data contenant la charge utile et les en-têtes). Les topics personnalisés Event Grid acceptent API Key (Event Grid appelle cela une « clé de topic », envoyée sous l'en-tête aeg-sas-key — définissez le champ Key exactement avec ce nom), OAuth 2.0 (une inscription d'application Entra ID), ou Event Grid SAS Token (un jeton à durée limitée que Business Central génère à partir d'une clé d'accès au topic). No Auth, Basic Auth, Azure SAS Token et Storage SAS Token ne s'appliquent pas à l'API d'Event Grid.

WARNING

Cela signifie que votre Event Grid Topic doit être configuré pour utiliser Event Grid Schema comme schéma d'entrée. Si le topic est configuré pour accepter CloudEvents v1.0 à la place, la publication sera rejetée — la forme JSON envoyée par Event Bridge ne correspond pas à ce qu'attend un topic au schéma CloudEvents. Vérifiez (ou définissez) ce paramètre dans le réglage Event Schema du topic, dans le portail Azure, avant d'y pointer Event Bridge.

Méthodes d'autorisation

No Auth

Aucun champ à configurer. Les requêtes sont envoyées sans en-tête Authorization — quiconque peut atteindre le point de terminaison peut lui envoyer des événements, et quiconque peut intercepter la requête peut les lire ; ⚠️ n'utilisez donc ceci que contre un point de terminaison en qui vous avez confiance et que vous contrôlez, comme une instance RabbitMQ sur un réseau privé, ou pour des tests locaux. Préférez Basic Auth ou OAuth 2.0 autrement.

Basic Auth

Champ	Remarques
Username	Envoyé comme nom d'utilisateur d'authentification de base.
Password	Masqué une fois enregistré — stocké chiffré, et il n'est plus possible de le consulter après saisie, uniquement de le remplacer.

API Key

Champ	Remarques
Key	Le nom de l'en-tête HTTP sous lequel la clé est envoyée.
Value	Masqué une fois enregistré, comme le mot de passe de Basic Auth — stocké chiffré, à remplacer plutôt qu'à consulter.

OAuth 2.0

Business Central obtient un jeton d'accès via le flux client-credentials et l'envoie comme jeton Bearer dans l'en-tête Authorization. Configurez ceci comme une inscription d'application dans le système cible (Entra ID, pour les points de terminaison Azure).

Champ	Remarques
Token Endpoint	L'URL du jeton OAuth2, par ex. https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token.
Client ID	L'ID d'application (client) de l'inscription d'application utilisée pour demander un jeton.
Scope	Un ou plusieurs scopes séparés par des espaces à demander — voir le tableau ci-dessous pour la valeur attendue par chaque point de terminaison Azure.
Client Secret	Masqué une fois enregistré, comme le mot de passe de Basic Auth — stocké chiffré, à remplacer plutôt qu'à consulter.

Le jeton d'accès est mis en cache en mémoire (par session) jusqu'à peu avant son expiration, plutôt que redemandé pour chaque événement. Si une requête revient malgré tout avec un 401 Unauthorized — par exemple parce que le jeton mis en cache a été révoqué ou que l'horloge du système cible est désynchronisée — Business Central rejette le jeton mis en cache et retente une fois avec un jeton fraîchement obtenu avant d'abandonner.

Configuration de l'inscription d'application Entra ID (pour les quatre points de terminaison Azure — RabbitMQ et API endpoint peuvent utiliser n'importe quel fournisseur OAuth2, cette partie ne s'applique donc pas à eux) :

1. Dans le portail Azure, allez dans Microsoft Entra ID → App registrations → New registration. Donnez-lui un nom (par ex. « BC Event Bridge ») et laissez l'URI de redirection vide — il s'agit d'une application client-credentials, pas d'une connexion interactive.
2. Sur la page Overview de la nouvelle inscription, copiez l'Application (client) ID dans Client ID, et le Directory (tenant) ID pour construire le Token Endpoint : https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token.
3. Allez dans Certificates & secrets → New client secret, et copiez immédiatement la Value du secret dans Client Secret — elle n'est affichée qu'une seule fois (le Secret ID situé à côté n'est pas ce dont vous avez besoin).
4. Accordez à l'inscription d'application l'accès à la ressource Azure cible. Cela se fait sur le volet Access control (IAM) de la ressource elle-même dans le portail, en tant qu'attribution de rôle avec l'inscription d'application comme membre — pas sur l'onglet API permissions de l'inscription d'application elle-même, qui concerne les permissions Microsoft Graph/déléguées et ne s'applique pas ici. Le rôle intégré à attribuer, et le Scope à définir dans Business Central, dépendent du point de terminaison :

Point de terminaison	Rôle à attribuer, et où	Scope
Azure Service Bus	Azure Service Bus Data Sender, sur l'espace de noms (ou plus restreint, sur la file d'attente/topic spécifique)	https://<namespace>.servicebus.windows.net/.default
Azure Event Hub	Azure Event Hubs Data Sender, sur l'espace de noms (ou plus restreint, sur l'Event Hub spécifique)	https://<namespace>.servicebus.windows.net/.default
Azure Queue Storage	Storage Queue Data Message Sender, sur le compte de stockage (ou plus restreint, sur la file d'attente spécifique)	https://storage.azure.com/.default
Azure Event Grid	EventGrid Data Sender, sur le topic personnalisé	https://eventgrid.azure.net/.default

Le rôle est ce qui autorise réellement la requête ; le scope indique simplement à Entra ID pour quelle ressource émettre le jeton.

Azure SAS Token

Signe chaque requête avec une stratégie d'accès partagé provenant d'Azure Service Bus ou d'Azure Event Hub — les deux partagent la même API REST de messagerie, cette méthode fonctionne donc de façon identique pour l'un ou l'autre : Business Central calcule une signature HMAC-SHA256 sur l'URL de la requête et une expiration de 5 minutes, et l'envoie comme en-tête Authorization de type SharedAccessSignature. Il s'agit du même schéma que celui utilisé par les chaînes de connexion propres à ces services.

Champ	Remarques
SAS Key Name	Le nom de la stratégie d'accès partagé, par ex. RootManageSharedAccessKey.
Key Value	Masqué une fois enregistré, comme le mot de passe de Basic Auth — stocké chiffré, à remplacer plutôt qu'à consulter. La clé primaire ou secondaire de la stratégie d'accès partagé.

Storage SAS Token

Ajoute un jeton de signature d'accès partagé pré-généré à l'URL de la requête sous forme de chaîne de requête, plutôt que de signer quoi que ce soit lui-même. Générez le jeton vous-même — limité à la file d'attente spécifique et à la permission Add message — via le portail Azure, Storage Explorer, ou l'Azure CLI, puis collez-le intégralement.

Champ	Remarques
SAS Token	Collez le jeton complet, avec ou sans le ? initial. Il est ajouté tel quel à l'URL de la requête et doit être renouvelé avant son expiration — contrairement à OAuth 2.0, Event Bridge ne peut pas le renouveler pour vous.

Event Grid SAS Token

Contrairement à Storage SAS Token, vous ne générez pas ce jeton vous-même — Business Central construit un jeton signé et frais pour chaque requête à partir d'une clé d'accès à longue durée de vie, et l'envoie sous l'en-tête aeg-sas-token (le schéma propre à Event Grid, distinct de l'en-tête générique Authorization utilisé par les autres méthodes).

Champ	Remarques
Access Key	La clé d'accès primaire ou secondaire du topic, provenant de Access keys sur le topic Event Grid dans le portail Azure. Masquée une fois enregistrée, comme le mot de passe de Basic Auth — stockée chiffrée, à remplacer plutôt qu'à consulter.

Chaque jeton généré est valide 60 minutes ; Business Central en régénère un pour chaque événement, il n'y a donc rien à renouveler manuellement.

Qui peut configurer ceci

Modifier Authorization nécessite le même ensemble de permissions Event Bridge Admin que le reste de Setup — voir Licensing and access.