Authentification REST sortante

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 2 minutes de lecture
  • Les messages REST sortants prennent en charge plusieurs types d’authentification.

    Différents fournisseurs de services Web peuvent exiger un type d’authentification spécifique. Le REST sortant prend en charge les formats d’authentification suivants.
    • Authentification de base à l’aide d’un nom d’utilisateur et d’un mot de passe
    • OAuth 2.0 utilisant un fournisseur et un profil OAuth
    • Authentification réciproque à l’aide de profils de protocole

    Limites de RESTMessage

    Les options suivantes sont prises en charge dans l’étape REST (Centre d’intégration), mais ne sont pas disponibles dans l’API scriptée RESTMessageV2 :

    Tableau 1. Limites de RESTMessage
    Limitation Description
    Authentification réciproque sur serveur MID mTLS (authentification par certificat client) n’est pas pris en charge lors de l’acheminement des appels REST via un serveur MID. L’authentification réciproque via RESTMessageV2 n’est prise en charge que pour les appels d’instance directe.
    Plusieurs parties avec pièces jointes Les demandes de type contenu en plusieurs parties pour l’envoi de pièces jointes ne sont pas prises en charge.
    Authentification personnalisée (algorithme d’authentification) Il n’existe pas de profils d’authentification personnalisés utilisant le cadre de travail de l’algorithme d’authentification.
    Authentification AWS (algorithme d’authentification) L’authentification AWS Signature version 4 via le cadre de travail de l’algorithme d’authentification n’est pas prise en charge.
    Politique des nouveaux essais pour les appels sortants Il n’existe pas de politiques de nouvelle tentative configurables intégrées pour les nouvelles tentatives automatiques sur les défaillances temporaires. La logique de nouvelle tentative personnalisée doit être implémentée dans le script.
    Remarque :
    Vous pouvez utiliser l’étape REST sur Centre d’intégration pour ces options.

    Remplacement de l’authentification REST

    Vous pouvez définir l’authentification pour un message REST, ou individuellement pour chaque méthode HTTP. Les méthodes HTTP héritent de l’authentification de leur enregistrement de message REST parent lorsque le type d’authentification de la méthode HTTP est Hériter du parent, qui est la valeur par défaut.

    Vous pouvez désactiver l’authentification pour une méthode HTTP spécifique en définissant le champ Type d’authentification sur Aucune authentification, ou spécifier une authentification différente du message REST parent en sélectionnant l’authentification de base ou OAuth.

    Exigences en matière d’authentification

    Les exigences d’authentification pour REST sortant sont les suivantes :

    • Le REST sortant prend en charge l’authentification réciproque uniquement lors de l’utilisation de l’authentification de base. L’authentification réciproque n’est pas disponible avec OAuth 2.0.
    • OAuth 2.0 ne peut être utilisé qu’avec des messages qui ne sont pas configurés pour utiliser un serveur MID. Vous ne pouvez pas envoyer de messages authentifiés OAuth 2.0 via un serveur MID. En outre, l’authentification réciproque n’est pas prise en charge avec Serveur MID.
    • Lorsque vous scriptez de nouveaux messages REST configurés avec authentification, vous devez utiliser l’API RESTMessageV2. Les API RESTMessage héritées ne prennent pas en charge les formats d’authentification actuels.
    • Les informations d’identification AWS ou toute autre authentification personnalisée ne sont prises en charge qu’avec , REST step et non avec l’API RestMessage.