Identifiants, Runtime Token et OAuth dans OpenConnector

Accès au runtime et identifiants des services

Les identifiants administrateur protègent la console et /api. Les Runtime Tokens autorisent les clients /v1 et /mcp. Les identifiants des services appartiennent aux comptes connectés et restent dans le runtime. Ils ne sont pas interchangeables.

Enregistrer votre application OAuth

En auto-hébergement, enregistrez une application OAuth auprès du service et copiez exactement expectedRedirectUri depuis /api/oauth/configs. Définissez OOMOL_CONNECT_ORIGIN avec l’origine publique avant de configurer un retour distant. Choisissez les autorisations nécessaires à votre usage.

Choisir la connexion du compte

Sans alias, l’appel utilise la connexion par défaut du service. Sélectionnez une connexion nommée avec x-oo-connector-alias. Les droits du Runtime Token peuvent limiter les comptes accessibles au client.

Conserver et protéger les identifiants

L’image Docker utilise /app/data pour les données locales du runtime. Montez un volume persistant. Configurez OOMOL_CONNECT_ENCRYPTION_KEY pour chiffrer les identifiants stockés et conservez la clé pour la récupération. Consultez le guide avant d’exposer le runtime.

Terminer la connexion OAuth

1. Définissez d’abord OOMOL_CONNECT_ORIGIN avec l’adresse utilisée par votre navigateur. Consultez /api/oauth/configs et recopiez exactement l’expectedRedirectUri du fournisseur dans votre application OAuth. Ajoutez le jeton Bearer administrateur si l’authentification administrateur est activée.
2. Dans la console locale, enregistrez le Client ID et le Secret OAuth du fournisseur. Si nécessaire, sélectionnez un sous-ensemble des scopes déclarés, lancez l’autorisation puis approuvez l’accès dans le navigateur du fournisseur.
3. Après le callback, consultez /api/connections et vérifiez l’identité du compte et le nom de connexion avant d’appeler une Action. Une connexion nommée doit déjà exister : sélectionner un alias ne la crée pas.

La première requête ci-dessous vérifie les connexions avec le jeton administrateur. La seconde appelle une Action en lecture seule avec le jeton runtime et une connexion work existante. Remplacez ce nom par le vôtre ; omettez l’en-tête d’alias pour la connexion par défaut.

curl -s http://localhost:3000/api/connections \
  -H "Authorization: Bearer $OOMOL_CONNECT_ADMIN_TOKEN"

curl -s -X POST \
  http://localhost:3000/v1/actions/github.get_current_user \
  -H "Authorization: Bearer $OOMOL_CONNECT_RUNTIME_TOKEN" \
  -H 'x-oo-connector-alias: work' \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Lire le résultat

Les réponses HTTP du runtime contiennent success, message, data et meta. Vérifiez success et le schéma de sortie de l’Action, pas seulement le statut HTTP. Si les métadonnées contiennent executionId, utilisez-le pour retrouver le journal expurgé correspondant. L’exemple ci-dessous illustre le format ; ce n’est pas un résultat d’appel réel.

{
  "success": true,
  "message": "OK",
  "data": {},
  "meta": {}
}

En cas d’échec

• Pour une erreur d’authentification, vérifiez l’endpoint et le type d’identifiant : l’accès administrateur protège /api, le jeton Bearer runtime autorise /v1 et /mcp. Une clé API fournisseur ne remplace pas le jeton runtime.
• Pour un refus d’accès, vérifiez les scopes requis, les règles d’Actions et les autorisations de connexion. Un jeton valide peut ne pas être autorisé à utiliser le compte choisi.
• Si le résultat est vide ou incomplet, vérifiez le compte connecté et ses droits sur la ressource. Une autorisation réussie ne donne pas accès à tous les espaces, canaux ou documents.
• Consultez l’erreur et le journal avant de réessayer. Si l’Action modifie les données du fournisseur, vérifiez d’abord si elle a déjà abouti ; ne répétez pas la requête aveuglément.