Pour configurer de nouvelles méthodes d'authentification pour les connecteurs de données, allez dans Paramètres > Intégrations > Authentication et cliquez sur Ajouter un token.
Vous avez deux approches principales pour configurer un token : connecter un fournisseur préconfiguré ou créer un token personnalisé :
Connexion à un fournisseur préconfiguré (OAuth)
Nous proposons des flux OAuth 3-legged préconfigurés pour les fournisseurs supportés (comme Salesforce, HubSpot et Attio) pour rendre l'authentification rapide et fluide.
Pour connecter l'un de ces fournisseurs :
Allez dans Paramètres > Intégrations > Authentication et cliquez sur Ajouter un token.
Sélectionnez le fournisseur souhaité dans le menu déroulant.
Vous serez redirigé vers la page d'autorisation du fournisseur. Vérifiez les permissions demandées et cliquez sur Confirmer (ou Autoriser) pour autoriser la connexion.
Une fois le flux OAuth terminé, votre nouveau token d'accès apparaîtra automatiquement dans votre liste de tokens.
Cliquer sur votre token nouvellement créé affichera sa configuration. Comme il s'agit d'une intégration préconfigurée, seuls les champs Nom et Description sont modifiables. Vous verrez également :
URL API : L'URL de base à utiliser pour effectuer des appels API à ce fournisseur dans vos connecteurs de données. Vous pouvez la copier rapidement avec l'icône Copier dans le presse-papiers.
Portée : Une liste en lecture seule des permissions accordées au token.
Réauthentification d'un token
Si un token devient désactivé ou invalide côté fournisseur, vous n'avez pas besoin de le supprimer et de recommencer. Ouvrez simplement les détails du token et cliquez sur le bouton Réauthentifier en haut à droite. Cela vous fera passer à nouveau par le flux OAuth et mettra automatiquement à jour votre token existant, garantissant que vos connecteurs de données connectés continuent de fonctionner sans mises à jour manuelles.
Création d'un token personnalisé
Si vous devez vous connecter à un service qui n'est pas inclus dans la liste préconfigurée :
Allez dans Paramètres > Intégrations > Authentication et cliquez sur Ajouter un token.
Sélectionnez Personnalisé.
Puis sélectionnez le Type de token que vous souhaitez créer dans le menu déroulant.
Tokens texte
Les tokens texte sont statiques. Vous pouvez définir le nom, la description, la valeur, le préfixe du token et la clé pour l'en-tête de requête contenant le token, qui sera inséré dans la requête du connecteur de données.
Tokens de requête HTTP
Les tokens de requête HTTP sont dynamiques. Vous configurez une requête HTTP vers votre point de terminaison d'authentification qui rafraîchira le token si nécessaire. Ces tokens doivent être testés depuis l'interface d'authentification des tokens avant d'être enregistrés. Vous pouvez définir le nom, la description du token, puis les champs qui affectent la requête elle-même : méthode HTTP, URL, en-têtes HTTP et paires clé-valeur.
Vous devez tester le token en cliquant sur Tester la requête puis spécifier l'emplacement du token dans la réponse, le préfixe du token et la clé pour l'en-tête de requête.
Si un token de requête HTTP est assigné à un connecteur de données, le connecteur utilisera le token le plus récemment récupéré pour ses requêtes. Si une requête retourne une réponse 400, 401 ou 403, le token sera rafraîchi en envoyant une requête HTTP à l'URL du point de terminaison d'authentification spécifié. La requête originale du connecteur de données sera alors réessayée avec le token fraîchement récupéré.
Les tokens de requête HTTP sont rafraîchis automatiquement par Intercom pour maintenir le fonctionnement des connecteurs de données. Ces mises à jour se font en arrière-plan sans intervention humaine et peuvent apparaître comme mises à jour par “System” ou “Fin” pour indiquer un rafraîchissement automatisé.
Note : Si votre serveur renvoie un 200 pour une réponse d'accès refusé, nous ne rafraîchirons pas le token. Vous devrez mettre à jour vos serveurs pour qu'ils renvoient un 400, 401 ou 403 dans ce cas.
En cas de problème lors du rafraîchissement d'un token, le problème sera enregistré dans l'onglet « Journaux » du connecteur de données.
Tokens de requête OAuth
Les requêtes OAuth vous permettent de demander et de rafraîchir un token en effectuant une requête POST avec le format OAuth client credentials grant.
Veuillez fournir le url, client_id, client_secret et le champ optionnel scope. Sélectionnez le format de requête JSON ou Form Encoded selon la configuration de votre serveur de tokens.
Un aperçu de l'en-tête et du corps de la requête s'affichera.
Cliquez sur Tester la requête une fois tous les champs requis remplis.
Intercom recherchera le token dans la réponse au chemin access_token.
Enregistrez le token une fois le test réussi.
Comme pour le token de requête HTTP, le système effectuera un rafraîchissement du token si une requête du connecteur de données reçoit une réponse 400, 401 ou 403.
Les tokens de requête OAuth sont rafraîchis automatiquement par le système lorsque nécessaire. Ces mises à jour ne sont pas déclenchées par un administrateur humain et peuvent apparaître comme mises à jour par “System” ou “Fin” pour indiquer un rafraîchissement automatisé.
Tokens utilisateur
Les tokens utilisateur permettent d'authentifier les connecteurs de données en utilisant un token défini par l'utilisateur. Ces tokens sont créés et mis à jour par des systèmes tiers. L'un des exemples les plus populaires de ce type de token est le JSON Web Tokens (JWT).
JWT est un moyen sécurisé de vérifier l'identité d'un utilisateur. Vous pouvez désormais utiliser ce nouveau type de token d'authentification pour sécuriser vos connecteurs de données. Cela permet une communication plus flexible et sécurisée entre vos systèmes et Intercom.
Utiliser le token dans un connecteur de données
Une fois votre type de token créé :
Allez dans Paramètres > Intégrations > Connecteurs de données et ouvrez le connecteur que vous souhaitez configurer.
Sélectionnez l'onglet API.
Dans la section Authentication tokens, sélectionnez votre token dans le menu déroulant.
Création et mise à jour des tokens utilisateur
Toute la gestion des tokens utilisateur est prise en charge par des systèmes tiers.
Intercom('boot', {
app_id: 'abc12345',
email: 'john.doe@example.com',
created_at: 1234567890,
name: 'John Doe',
user_id: '9876',
auth_tokens: {
security_token: 'abc...' // JWT
}
});
Ces systèmes tiers sont également responsables de la mise à jour du token de sécurité et de son actualisation périodique.
Intercom('update', {
app_id: 'abc12345',
auth_tokens: {
security_token: 'bcd...' // JWT
}
});
Intercom('setAuthTokens', {
security_token: 'abc...' // JWT
});
# Swift
Intercom.setAuthTokens({
security_token: 'abc...' // JWT
});
# Kotlin
Intercom.client().setAuthTokens({
security_token: 'abc...' // JWT
});
Prise en charge multi-token
Vous pouvez attacher plusieurs tokens à un seul Data connector. Chaque token attaché doit être configuré avec une clé d’en-tête unique (par exemple, Authorization, X-API-Key). Tous les tokens attachés seront envoyés avec la requête.
Cette configuration vous permet de déclencher des Data connectors en utilisant ce token - soit via Workflows, soit via Fin. Le Data connector continuera de fonctionner même si la valeur du token est mise à jour, car elle sera actualisée en temps réel pour garantir une authentification ininterrompue.
Pour utiliser un JWT par utilisateur avec un Data connector, créez un token d’authentification « User » et fournissez sa valeur actuelle via auth_tokens (par exemple, Intercom('setAuthTokens')), plutôt que de compter sur le Messenger intercom_user_jwt.
Vérification par e-mail avec un code à usage unique (OTP)
La vérification par e-mail pour les Data connectors avec OTP ajoute une étape de vérification supplémentaire avant l’utilisation d’un Data connector en demandant aux clients de confirmer leur identité via un code unique et temporaire envoyé par e-mail.
Cette méthode ajoute une couche de sécurité supplémentaire en plus des tokens d’authentification utilisateur (par exemple, JWT). Lorsqu’elle est activée, les clients doivent compléter le processus de vérification par e-mail avant que le Data connector puisse continuer. Cela garantit que seuls les utilisateurs autorisés peuvent effectuer des opérations sensibles et empêche l’utilisation abusive des workflows automatisés.
Authentification client pour les data connectors
L’authentification client vous permet de vérifier l’identité d’un client avant l’exécution d’un data connector. Contrairement à l’authentification par token API (qui sécurise la communication serveur à serveur), l’authentification client confirme l’identité de l’utilisateur final — garantissant que seuls les clients autorisés peuvent déclencher des connecteurs sensibles.
Les règles d’authentification sont configurées dans Paramètres > Espace de travail > Sécurité > Authentification client et s’appliquent à tous les data connectors avec authentification activée. Les règles peuvent être définies par canal et par audience.
Une règle de secours couvre tous les canaux et audiences non spécifiés, assurant ainsi que chaque connecteur authentifié est toujours protégé.
Nouvel espace de travail
Lorsqu’un nouvel espace de travail est créé, la règle d’authentification de secours est automatiquement définie sur Email OTP. Cela couvre tous les canaux et audiences non spécifiés par une règle plus spécifique.
Ajout d’une règle
Lorsque vous créez une nouvelle règle de canal ou d’audience, une méthode d’authentification par défaut est appliquée selon le type de canal :
Canal | Méthode de vérification par défaut |
Messenger (web, iOS, Android) | Sécurité Messenger (JWT) |
Tous les autres canaux | Pas de vérification (règle de secours appliquée) |
Méthodes de vérification
Deux méthodes de vérification sont disponibles :
Email OTP — envoie un code à usage unique à l’adresse e-mail du client. Le client doit saisir ce code avant que le connecteur ne s’exécute. Voir Sécuriser les data connectors avec un code à usage unique pour les détails de configuration.
Sécurité Messenger (JWT) — utilise votre vérification d’identité Messenger existante (User token). Nécessite la configuration de la sécurité Messenger avec JWT. Voir User tokens ci-dessus.
Astuce : La sécurité Messenger (JWT) offre la garantie d’identité la plus forte et est la méthode recommandée pour les conversations basées sur Messenger. Elle vérifie l’identité sans ajouter de friction pour vos clients.
Activer l’authentification sur un connecteur
L’authentification doit être activée individuellement pour chaque data connector où vous souhaitez l’appliquer :
Allez dans Paramètres > Intégrations > Data connectors et ouvrez le connecteur.
Sélectionnez l’onglet Sécurité.
Activez Authentification client.
Complétez les vérifications de sécurité, puis enregistrez et mettez le connecteur en ligne.
Une fois activé, le connecteur applique les règles d’authentification de l’espace de travail qui s’appliquent au canal et à l’audience de la conversation entrante.
Note : Si vous souhaitez qu’un data connector s’exécute sans exiger de vérification d’identité, vous pouvez désactiver complètement l’Authentification client. Ouvrez le connecteur, sélectionnez l’onglet Sécurité et désactivez Authentification client.
Vérifications de sécurité
Lorsque vous enregistrez un data connector, Intercom signale automatiquement les risques potentiels de sécurité dans votre configuration. Ceux-ci apparaissent sous forme d’avertissements dans l’onglet Sécurité et doivent être examinés avant de mettre le connecteur en ligne. Chaque avertissement décrit le risque et fournit une recommandation pour y remédier.
Avertissement | Ce que cela signifie | Comment y remédier |
Les attributs des données client ne sont pas vérifiés | Les attributs des données client peuvent être mis à jour par Fin sans que le client ait d’abord vérifié son identité. | Activez l’authentification client pour ce connecteur afin que les mises à jour des attributs soient liées à une identité vérifiée. |
Les données collectées par Fin pour ce connecteur nécessitent une révision | Fin collecte des informations auprès du client avant d’appeler votre API. Si cette entrée n’est pas validée, votre backend peut traiter des données non vérifiées ou manipulées. | Validez toutes les entrées reçues de Fin dans votre backend avant de les traiter ou de les stocker. Ne vous fiez pas aux valeurs fournies par le client sans vérifications côté serveur. |
Les Workflows utilisant ce data connector nécessitent une révision | Un ou plusieurs workflows utilisant ce connecteur peuvent exposer des données sensibles des clients sans validation backend suffisante. | Examinez les workflows signalés et ajoutez une validation backend pour empêcher l'exposition ou l'utilisation abusive des données sensibles. |
Un en-tête de requête pour ce connecteur de données nécessite une révision | Les détails du client (comme l'adresse e-mail) sont envoyés en tant qu'en-tête de requête — par exemple, | Assurez-vous que votre API backend valide la valeur de l'en-tête qu'elle reçoit au lieu de la considérer telle quelle. |
Note : Le badge « Insecure » affiché sur un attribut individuel du connecteur (par exemple pour une valeur collectée par Fin qui n'est pas vérifiée) est différent des avertissements résolubles de l'onglet Sécurité ci-dessus. C'est un indicateur permanent, conçu pour toute valeur non vérifiée/insécurisée collectée par Fin — toute action de rejet dans la vue d'édition du connecteur ne le supprime pas, et il réapparaîtra même après que vous ayez examiné l'attribut et confirmé qu'il est sûr à utiliser. Ce n'est pas une alerte actionnable que vous pouvez résoudre ou rejeter définitivement ; cela signale simplement que la valeur n'a pas été vérifiée via l'authentification client. Si vous souhaitez que cette catégorie d'attribut cesse d'être signalée, la seule façon est d'activer l'authentification client pour le connecteur (voir ci-dessus) afin que la valeur soit liée à une identité vérifiée.
Identifiants
La page Identifiants (Paramètres > Intégrations > Identifiants) vous offre une vue centralisée de tous les identifiants d'authentification utilisés dans vos connecteurs de données. Le tableau affiche le nom, le type, qui l'a créé et qui l'a mis à jour en dernier — facilitant ainsi l'audit des accès aux systèmes externes.
Logique
Les jetons basés sur du texte sont simples — le connecteur de données utilise la valeur du jeton assigné chaque fois qu'il teste ou envoie une requête en direct.
Les jetons de requête HTTP suivent un processus plus complexe. Pour les connecteurs de données en test et en direct, le connecteur de données utilise d'abord le jeton récupéré le plus récemment. Si la requête échoue, il envoie une requête de rafraîchissement puis retente la requête avec le nouveau jeton. Cette nouvelle tentative n'a lieu qu'une seule fois pour éviter une boucle infinie.
Si le connecteur de données continue d'échouer à cause d'échecs des requêtes de rafraîchissement, il déclenchera le disjoncteur, comme tout connecteur de données rencontrant des échecs répétés.
Limitations connues
Actuellement, ni les jetons d'authentification Text ni HTTP Request ne supportent des détails de requête d'authentification différents par client. Cela est généralement demandé sous la forme d'un flux OAuth complet.
Une fois le jeton d'authentification créé, il n'est pas possible de le supprimer.
Les connecteurs de données utilisant le jeton d'application Stripe autogénéré ne supportent pas la fonctionnalité multi-jetons car les en-têtes sont verrouillés en lecture seule. Pour effectuer des modifications, vous devez d'abord supprimer ou remplacer le jeton Stripe.
Une fois un jeton Stripe sélectionné, vous ne pouvez pas ajouter de nouvelles paires clé-valeur à la section HTTP Headers.