Passer au contenu principal

Authentification

Copilot SDK prend en charge plusieurs méthodes d’authentification. Choisissez celle adaptée à votre cas d’usage.

Méthodes d’authentification

Pour BYOK, voir Custom providers.

Microsoft Entra ID

Pour utiliser la connexion Microsoft Entra intégrée et le renouvellement des tokens, enregistrez votre application hôte auprès du client. Définissez clientId sur l’ID d’application (client) de l’enregistrement de votre application Entra. Vous pouvez passer une instance de EntraAuthConfig ou un tableau. Les valeurs vides ou composées uniquement d’espaces lèvent une InvalidArgumentException.
Vous pouvez aussi passer un tableau :
Le SDK envoie l’ID client au runtime lors du handshake server.connect. Cet enregistrement est distinct du RPC serveur accounts.acquireEntraToken, qui demande explicitement un token. Si vous définissez une configuration Entra et que le runtime est trop ancien pour prendre en charge connect, le SDK lève This runtime does not support Entra client configuration. au lieu d’ignorer silencieusement le paramètre. Dans ce cas, mettez à jour le runtime. Les autres méthodes d’authentification continuent de fonctionner.

Callbacks réseau

L’option network permet de déléguer la résolution de proxy et l’authentification Kerberos Negotiate du runtime à des callbacks côté hôte. Le runtime Copilot utilisé doit prendre en charge le RPC network.setProvider. Sinon, le client lève au démarrage une exception qui vous invite à mettre à jour le runtime. Chaque callback reçoit le type de requête et un CancellationToken qui permet de vérifier l’annulation.
resolveProxy renvoie une chaîne de style PAC comme PROXY proxy.example:8080; DIRECT, ou DIRECT pour une connexion directe. Renvoyez null pour laisser le runtime résoudre lui-même le proxy. authenticateNegotiate renvoie un jeton SPNEGO en base64 à usage unique sans le préfixe Negotiate , ou null lorsqu’aucun identifiant n’est disponible. Si un callback lève une exception, le RPC échoue et il n’y a pas de repli sur une connexion directe. Validez le SPN avant d’émettre des identifiants. scope vaut connection par défaut, ce qui ne couvre que les requêtes des sessions créées ou reprises par ce client. runtime couvre également les communications partagées en arrière-plan, mais une seule connexion à la fois peut détenir ce scope.

Connexion GitHub (CLI)

Si vous êtes déjà connecté au CLI copilot ou gh, les identifiants enregistrés sont utilisés lorsque rien n’est spécifié.

GitHub App OAuth / PAT

Passez à github_token un token d’accès utilisateur obtenu via le flux OAuth ou un PAT à granularité fine.
  • Formats attendus : gho_ / ghu_ / github_pat_
  • ghp_ (PAT classique) est déconseillé
En spécifiant github_token, use_logged_in_user bascule automatiquement à false. Pour l’activer explicitement :
Voir GitHub token pour plus de détails. github_token et use_logged_in_user ne sont utilisables qu’en mode stdio. En mode TCP, l’authentification doit être effectuée côté Copilot CLI.

Masquer les secrets générés par l’hôte

Si votre application hôte obtient des tokens dynamiquement, par exemple via MCP OAuth, enregistrez-les auprès du filtre de masquage du Copilot CLI. Le CLI masque les valeurs enregistrées dans les journaux et les exports de session.
Cet appel est distinct de l’obtention et de la transmission des tokens avec onMcpAuthRequest. Appelez-le explicitement après avoir obtenu un token. Le SDK ne persiste pas les valeurs et ne les journalise pas séparément pour ce RPC.

Variables d’environnement

Si vous transmettez le token via une variable d’environnement, le CLI le détecte automatiquement. L’ordre de priorité est le suivant, du plus prioritaire au moins prioritaire :
  1. COPILOT_GITHUB_TOKEN
  2. GH_TOKEN
  3. GITHUB_TOKEN
En mode TCP, configurez les variables d’environnement côté serveur CLI.

Priorité de l’authentification

Le SDK résout les identifiants dans l’ordre suivant :
  1. github_token (spécifié explicitement)
  2. Tokens de variables d’environnement (COPILOT_GITHUB_TOKEN → GH_TOKEN → GITHUB_TOKEN)
  3. Identifiants OAuth enregistrés dans le CLI
  4. Identifiants du CLI gh

Désactiver l’auto-connexion

Pour ne pas utiliser les identifiants enregistrés, mettez use_logged_in_user à false. Avec false, seul le token fourni explicitement (github_token) est utilisé pour l’authentification. Les tokens des variables d’environnement (COPILOT_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN) sont ignorés.
Comme pour github_token, cela ne fonctionne qu’en mode stdio. En mode TCP, l’authentification doit être faite côté Copilot CLI.

Vérifier l’état d’authentification

Vous pouvez récupérer et inspecter le résultat de auth.getStatus.

Sélectionner un compte pour la connexion interactive

Énumérez loginAccounts via le RPC de session pour obtenir les identités enregistrées que vous pouvez réutiliser avec un fournisseur donné. Le label de chaque élément sert à l’affichage, et active indique si l’identité correspond au compte actif de la session courante. accountId est un identifiant opaque appartenant au fournisseur. Transmettez-le tel quel à la requête de connexion, sans l’analyser ni le modifier.
Utilisez mode: 'default' pour réutiliser une identité enregistrée avec le comportement normal du fournisseur. Utilisez mode: 'selectAccount' pour afficher explicitement le sélecteur de compte du fournisseur. Dans ce cas, ne passez pas accountId. Les appels existants comme begin(LoginProviderKind::ENTRA) continuent de fonctionner.
Pour les dernières informations, consultez le dépôt GitHub.
Dernière modification le 9 novembre 2026