Connexions OAuth
Interrogez une API fournisseur authentifiée par OAuth — la plateforme résout le compte de la connexion et fournit à votre source un jeton d'accès valide
Une source déclarative en mode poll nomme l'identifiant dont elle a besoin avec authRef. Lorsque la connexion configurée par l'organisation pour cette source est une clé d'API, authRef se résout en credentials.apiKey. Lorsqu'il s'agit d'une connexion OAuth, il se résout en credentials.accessToken — un jeton valide au moment où votre tick s'exécute.
Rien dans le manifeste ne choisit entre les deux. L'organisation choisit au moment de configurer la connexion ; la plateforme résout ce que cette connexion porte.
Ce que la plateforme fournit à votre source
| Mode d'authentification de la connexion | Champ credentials reçu |
|---|---|
api_key, bot_token | apiKey |
oauth, oauth_app, oauth_client_credentials | accessToken |
none | (aucun identifiant — la source est sans clé) |
basic_auth | (refusé — un nom d'utilisateur et un mot de passe ne sont pas un secret unique à placer sur une requête ; le tick renvoie HTTP 412 data_source_connection_required) |
Placez-le avec request.auth. credential: "accessToken" envoie le jeton OAuth là où le fournisseur l'attend :
request: {
url: "https://graph.microsoft.com/v1.0/me/messages",
authRef: "primary",
auth: { placement: "bearer", credential: "accessToken" },
}credential nomme un champ, jamais une valeur. Un manifeste ne contient jamais de jeton, d'identifiant client ni de secret client — ceux-ci vivent sur la connexion configurée par l'organisation, et seule la plateforme les lit.
La fraîcheur du jeton incombe à la plateforme, pas à vous
La plateforme résout le jeton à chaque tick, juste avant la construction de votre requête :
- Elle trouve le compte d'exécution par défaut de la connexion.
- Elle vérifie l'expiration de ce compte et, si le jeton est expiré ou proche de l'expiration, échange le jeton de rafraîchissement stocké (ou, pour
oauth_client_credentials, réacquiert un jeton avec les identifiants client) puis persiste le résultat. - Elle fournit à votre source le jeton d'accès obtenu.
Une source poll ne voit donc jamais de jeton périmé et n'a jamais besoin de sa propre logique de rafraîchissement.
Votre source reçoit le jeton d'accès et rien d'autre. Le jeton de rafraîchissement, le secret client et l'expiration restent dans la plateforme. Il est délibérément impossible à une source de données de créer un nouvel identifiant — elle ne peut dépenser que celui qui lui a été remis, pour le seul tick concerné.
Quand la connexion demande une intervention
Si la plateforme ne peut pas produire de jeton valide, le tick ne s'exécute pas et la source signale un problème de configuration plutôt qu'un échec de requête. Cela se produit lorsque :
- la connexion n'a aucun compte connecté (personne n'a terminé la connexion OAuth) ;
- le compte a été marqué comme nécessitant une réautorisation (consentement révoqué, mot de passe modifié, application retirée par un administrateur) ;
- le rafraîchissement lui-même a échoué côté fournisseur.
Ces trois cas se manifestent comme une clé d'API manquante : la plateforme lève CAPABILITY_NOT_CONFIGURED et le tick de source de données renvoie HTTP 412 avec error: "data_source_connection_required". La correction est toujours la même — reconnecter le compte sur la connexion dans les paramètres de l'organisation.
Un compte n'est résolu que depuis la même organisation et la même connexion auxquelles la source est liée. Un compte connecté pour une autre organisation, ou rattaché à une autre connexion, n'est jamais emprunté — le tick signale data_source_connection_required à la place.