Jetons d’accès

Les jetons d’accès Codex sont des identifiants d’espace de travail ChatGPT dont la portée se limite aux autorisations Codex. Ils permettent aux workflows locaux de confiance de s’authentifier sans intervention humaine avec une identité de l’espace de travail ChatGPT. Cela inclut les workflows qui utilisent Codex CLI ou s’appuient sur App Server. Utilisez ces jetons lorsqu’un script, une tâche planifiée ou un runner de CI doit pouvoir accéder à Codex localement à chaque exécution.

Pour créer des jetons d’accès personnels, ouvrez la page Jetons d’accès dans la console d’administration de ChatGPT. Chaque jeton est rattaché à la personne qui l’a créé et à son espace de travail ChatGPT. Ces jetons servent d’identités d’agent pour les workflows locaux exécutés par programme. Pour créer un jeton depuis la fiche d’une identité non humaine dédiée dans l’espace de travail, consultez la page Comptes de service.

Fonctionnement des jetons d’accès

Utilisez un jeton d’accès lorsque Codex CLI ou un client App Server doit fonctionner sans qu’un utilisateur ait à se connecter dans un navigateur. Le jeton représente l’utilisateur de l’espace de travail ChatGPT qui l’a créé. Les exécutions peuvent ainsi bénéficier de ses droits d’accès et figurer dans les données de gouvernance de l’espace de travail.

Au démarrage de chaque exécution, le client vérifie le jeton et associe l’exécution à cette identité de l’espace de travail. Traitez le jeton comme tout autre secret d’automatisation : conservez-le dans un gestionnaire de secrets, veillez à ce qu’il n’apparaisse pas dans les journaux et renouvelez-le conformément à la politique de votre organisation.

Utilisez des jetons d’accès dans les cas suivants :

• Tâches codex exec lancées par une automatisation de confiance.
• Scripts locaux qui doivent pouvoir exécuter Codex CLI à plusieurs reprises sans intervention humaine.
• Automatisations de confiance qui s’appuient sur App Server.
• Workflows d’entreprise qui associent l’utilisation à un utilisateur de l’espace de travail ChatGPT plutôt qu’à une clé API d’organisation.

Principaux risques à éviter :

• Divulgation de secrets : toute personne qui détient le jeton peut lancer des exécutions locales via Codex CLI ou un client App Server sous l’identité de la personne qui l’a créé. Conservez les jetons dans un gestionnaire de secrets, veillez à ce qu’ils n’apparaissent pas dans les journaux et renouvelez-les conformément à la politique de votre organisation.
• Runners non fiables : un environnement de CI public, des pull requests issues de forks ou des machines partagées peuvent exposer les jetons à des personnes extérieures à votre espace de travail. N’utilisez les jetons d’accès que sur des runners de confiance.
• Identités partagées : lorsque des équipes indépendantes réutilisent le jeton d’une même personne, il devient plus difficile d’identifier les responsables des workflows et de retracer leurs actions lors d’un audit. Créez chaque jeton pour la personne responsable d’un workflow précis.
• Identifiants obsolètes : les jetons de longue durée peuvent rester actifs après une modification du workflow. Privilégiez les jetons à durée limitée et révoquez ceux qui ne servent plus.
• Portée ou type d’identifiant inadapté : l’automatisation de Codex nécessite un accès à Codex, le déclenchement d’un agent de l’espace de travail nécessite un accès aux agents de l’espace de travail et les appels généraux à l’API OpenAI nécessitent une clé API de la plateforme. Si Portées s’affiche, accordez uniquement les autorisations nécessaires au workflow.

Activer la création de jetons d’accès

Dans les paramètres de l’espace de travail, activez l’autorisation relative aux jetons d’accès pour les membres qui doivent pouvoir en créer.

Cette autorisation contrôle la création de jetons. Elle ne donne pas accès à l’application de bureau ChatGPT, à Codex CLI ni à l’extension pour IDE. Elle ne modifie ni le type de licence du membre, ni son rôle prédéfini dans l’espace de travail, ni son profil d’autorisations pour l’exécution locale. Les workflows Codex CLI et App Server authentifiés par jeton exigent également que l’utilisateur dispose de l’autorisation d’utiliser Codex localement.

Pour comprendre comment ces autorisations s’articulent, consultez la page Rôles et autorisations de l’espace de travail.

1. Demandez à un propriétaire de l’espace de travail d’ouvrir Paramètres de l’espace de travail > Autorisations et rôles.
2. Si la section Jetons d’accès s’affiche, activez Autoriser les utilisateurs à créer des jetons d’accès personnels. Si cette section n’est pas disponible, activez Autoriser les membres à utiliser des jetons d’accès Codex dans Codex et Work en local ou Codex en local.
3. Pour le responsable du workflow, activez l’autorisation locale correspondante : Autoriser les membres à utiliser Codex et Work localement dans Codex et Work en local, ou Autoriser les membres à utiliser Codex localement dans Codex en local. Lorsque Work en local dispose de sa propre section, Utiliser Work localement contrôle l’accès au mode Work. Cette autorisation n’est pas nécessaire pour les jetons Codex.

Réservez la création de jetons d’accès aux personnes ou aux responsables de service qui savent où les jetons sont stockés, à quelles automatisations ils sont destinés et quand ils doivent être renouvelés.

La désactivation de l’autorisation d’utiliser Codex localement suspend les jetons Codex actifs des membres concernés sans les révoquer. Le rétablissement de l’accès local à Codex réactive ces jetons. Révoquez les jetons pour mettre définitivement fin à l’accès qu’ils accordent.

Définir la durée de validité maximale des jetons d’accès

Un propriétaire de l’espace de travail peut fixer la durée de validité maximale que les membres peuvent choisir pour leurs nouveaux jetons d’accès. Ouvrez Paramètres de l’espace de travail > Autorisations et rôles. Si la section Jetons d’accès s’affiche, définissez-y la Durée de validité maximale des jetons d’accès. Sinon, recherchez ce paramètre dans Codex et Work en local ou Codex en local.

La limite s’applique aux nouveaux jetons d’accès. Les jetons existants conservent leur durée de validité actuelle.

Créer un jeton d’accès

Sur la page Jetons d’accès, donnez un nom au jeton, vérifiez à quels produits il peut donner accès et choisissez une durée de validité adaptée.

1. Ouvrez la page Jetons d’accès.
2. Sélectionnez Créer.

3. Saisissez un nom descriptif, par exemple release-ci ou nightly-docs-check.

4. Si la boîte de dialogue affiche Portées, sélectionnez Codex. Sélectionnez Agents de l’espace de travail uniquement si le même workflow doit aussi déclencher un agent de l’espace de travail. Sans sélecteur de portée, la boîte de dialogue crée un jeton limité à Codex.
5. Choisissez une durée de validité limitée, par exemple 7, 30, 60 ou 90 jours. Les jetons d’accès personnels dont vous définissez la portée doivent avoir une date d’expiration. Une ancienne version de la boîte de dialogue, réservée à Codex, peut proposer l’option Sans expiration. Évitez cette option, sauf si votre organisation l’approuve et renouvelle le jeton selon un calendrier défini.
6. Sélectionnez Créer.
7. Copiez immédiatement le jeton d’accès généré. Vous ne pourrez plus le consulter après avoir fermé la boîte de dialogue.
8. Conservez le jeton dans votre gestionnaire de secrets ou dans le coffre de secrets de votre système de CI.

La durée de validité personnalisée minimale est d’un jour. Vous ne pouvez pas utiliser un jeton révoqué ou expiré pour lancer de nouvelles exécutions authentifiées.

Utiliser un jeton d’accès avec Codex CLI

Si la boîte de dialogue de création du jeton indique une version requise de Codex CLI, installez cette version ou une version ultérieure avant d’utiliser le jeton.

Pour une automatisation éphémère, placez le jeton dans CODEX_ACCESS_TOKEN et exécutez Codex CLI comme d’habitude :

export CODEX_ACCESS_TOKEN="<access-token>"
codex exec --json "review this repository and summarize the top risks"

Pour conserver l’authentification sur la machine, transmettez le jeton à codex login --with-access-token via l’entrée standard :

printf '%s' "$CODEX_ACCESS_TOKEN" | codex login --with-access-token
codex exec "summarize the last release diff"

codex login --with-access-token enregistre l’identifiant de l’agent dans le stockage des données d’authentification de Codex CLI. Si vous préférez éviter de conserver des identifiants sur la machine, utilisez la variable d’environnement CODEX_ACCESS_TOKEN.

codex app-server peut utiliser le même identifiant pour authentifier ses requêtes auprès d’OpenAI, soit via CODEX_ACCESS_TOKEN, soit via une connexion établie avec codex login --with-access-token. Cet identifiant est distinct de celui qui authentifie la connexion entre le client et App Server. Pour une connexion WebSocket distante, configurez un jeton au porteur ou un jeton de capacité distinct, comme indiqué dans la page App Server. Ne réutilisez pas le jeton d’accès Codex comme jeton de transport. Consultez la page Variables d’environnement pour l’authentification et le réseau.

Renouveler ou révoquer un jeton

Renouvelez les jetons d’accès comme vos autres secrets d’automatisation :

1. Créez un jeton de remplacement.
2. Mettez à jour le secret dans le runner, le planificateur ou le gestionnaire de secrets.
3. Effectuez un test rapide avec le nouveau jeton pour vérifier qu’il fonctionne.
4. Révoquez l’ancien jeton depuis la page Jetons d’accès.

Depuis la page Jetons d’accès, les propriétaires et les administrateurs peuvent révoquer n’importe quel jeton de l’espace de travail. Les membres qui disposent de l’autorisation relative aux jetons d’accès peuvent uniquement révoquer les jetons qu’ils ont créés.

Modèle d’autorisations

Dans l’espace de travail, l’autorisation relative aux jetons d’accès contrôle leur création. Selon l’organisation des paramètres, l’accès local à Codex dépend de l’option Autoriser les membres à utiliser Codex et Work localement dans Codex et Work en local, ou de l’option Autoriser les membres à utiliser Codex localement dans Codex en local. Si Work en local dispose de sa propre section, l’option Utiliser Work localement contrôle l’accès au mode Work et ne donne pas accès à Codex. Pour exécuter un workflow Codex authentifié par jeton, un membre doit disposer à la fois de l’accès local à Codex et de l’autorisation relative aux jetons d’accès. Un membre peut utiliser Codex localement sans avoir l’autorisation de créer des jetons d’accès.

Les propriétaires et les administrateurs gèrent les accès pour l’ensemble de l’espace de travail. Les membres ont besoin de l’autorisation relative aux jetons d’accès pour créer et gérer leurs propres jetons. Cette autorisation ne leur confère aucun droit d’administration ni aucun accès aux jetons des autres membres.

Dépannage

La page Jetons d’accès renvoie une erreur 404 ou refuse l’accès

Demandez à un propriétaire de l’espace de travail de vérifier que votre rôle inclut l’autorisation Autoriser les utilisateurs à créer des jetons d’accès personnels ou Autoriser les membres à utiliser des jetons d’accès Codex, selon l’interface disponible. Pour un workflow Codex authentifié par jeton, vérifiez également que l’option Autoriser les membres à utiliser Codex et Work localement ou Autoriser les membres à utiliser Codex localement est activée.

codex login --with-access-token échoue

Vérifiez que vous avez bien copié le jeton d’accès généré et que vous n’avez pas utilisé à sa place un jeton de session du navigateur ou une clé API de la plateforme. Vérifiez également que le jeton est actif, qu’il n’a pas expiré et qu’il appartient à un utilisateur disposant de l’autorisation requise pour utiliser Codex localement.

Documentation associée

• Authentification
• Comptes de service
• Mode non interactif
• Guide de déploiement pour les administrateurs
• Groupes et provisionnement
• Gestion du cycle de vie des utilisateurs
• Rôles et autorisations de l’espace de travail
• Gouvernance