Gestion de vos jetons d’accès personnels

À propos de personal access token

          Personal access tokensont une alternative à l’utilisation de mots de passe pour l’authentification GitHub lors de l’utilisation de l’API [GitHub](/rest/overview/authenticating-to-the-rest-api) ou de la [ligne de commande](#using-a-personal-access-token-on-the-command-line).

          Personal access tokensont destinés à accéder GitHub aux ressources en votre nom. Pour accéder aux ressources pour le compte d’une organisation ou pour des intégrations de longue durée, vous devez utiliser un GitHub App. Pour plus d’informations, consultez « [AUTOTITLE](/apps/creating-github-apps/setting-up-a-github-app/about-creating-github-apps) ».

          Un jeton possède les mêmes capacités d’accès aux ressources et d’exécution d’actions sur ces ressources que le propriétaire du jeton, et est en outre limité par toute portée ou autorisation accordée au jeton. Un jeton ne peut pas accorder des fonctionnalités d’accès supplémentaires à un utilisateur. Par exemple, un personal access token peut être configuré avec un champ de `admin:org`, mais si le propriétaire du jeton n'est pas propriétaire de l'organisation, le jeton ne donne pas l'accès administratif à l'organisation.

Types d’personal access token

          GitHub prend actuellement en charge deux types de personal access tokens : fine-grained personal access tokens et personal access tokens (classic). 
          GitHub recommande d’utiliser fine-grained personal access tokens au lieu de personal access tokens (classic) chaque fois que possible.

Les deux fine-grained personal access token sont et personal access tokens (classic) sont liés à l’utilisateur qui les a générés et deviendront inactifs si l’utilisateur perd l’accès à la ressource.

Les propriétaires d’organisations peuvent définir une stratégie pour restreindre l’accès à personal access tokens (classic) leur organisation, et les propriétaires d’entreprise peuvent restreindre l’accès à personal access tokens (classic) l’entreprise ou aux organisations détenues par l’entreprise. Pour plus d’informations, consultez « Définition d’une stratégie de jeton d’accès personnel pour votre organisation ».

Fine-grained personal access token

          Fine-grained personal access tokens présentent plusieurs avantages en matière de sécurité par rapport à personal access tokens (classic), mais ont également des limitations qui peuvent vous empêcher de les utiliser dans tous les scénarios. Ces limites, ainsi que nos projets pour y remédier, sont présentés dans la [section ci-dessous](#fine-grained-personal-access-tokens-limitations).

Si vous pouvez utiliser un fine-grained personal access token pour votre scénario, vous bénéficierez de ces améliorations :

• Chaque jeton est limité à l’accès aux ressources appartenant à un seul utilisateur ou à une seule organisation.
• Chaque jeton peut être limité à l’accès à des référentiels spécifiques pour cet utilisateur ou cette organisation.
• Chaque jeton reçoit des autorisations spécifiques et détaillées, qui offrent un contrôle plus fin que les permissions accordées à personal access tokens (classic).
• Les propriétaires de l’organisation peuvent exiger l’approbation pour tout fine-grained personal access token pouvant accéder aux ressources de l’organisation.
• Les propriétaires d’entreprise peuvent exiger l’approbation de tout fine-grained personal access token qui peut accéder aux ressources dans les organisations appartenant à l’entreprise.

Fine-grained personal access tokens Limitations

          Fine-grained personal access tokens ne prend pas en charge chaque fonctionnalité de personal access tokens (classic). Ces lacunes de fonctionnalités ne sont pas permanentes : GitHub travaille à les combler. Consultez [notre feuille de route publique](https://github.com/github/roadmap) pour obtenir plus de détails sur la date à laquelle ces scénarios seront pris en charge.

Les principales lacunes dans fine-grained personal access token sont les suivantes :

• Utilisation fine-grained personal access token pour contribuer aux dépôts publics où l’utilisateur n’est pas membre.

• L'utilisation de fine-grained personal access token pour contribuer aux référentiels où l'utilisateur est un collaborateur externe ou du référentiel.

• Utilisation fine-grained personal access token pour accéder à plusieurs organisations à la fois.

          * Utilisation fine-grained personal access token pour accéder `internal` aux ressources au sein d’une entreprise à laquelle appartient l’utilisateur.
  

• Utilisation fine-grained personal access token pour appeler des API qui gèrent le compte Entreprise.

          * Utilisation fine-grained personal access token pour accéder aux packages.
  

• Utilisation fine-grained personal access token pour appeler l’API Checks.

• Utilisation fine-grained personal access token pour accéder aux projets appartenant à un compte d’utilisateur.

Toutes ces lacunes seront résolues au fil du temps, car GitHub elles continuent d’investir dans des modèles d’accès plus sécurisés.

Personal access tokens (classic)

Les Personal access tokens (classic) sont moins sécurisés. Cependant, certaines fonctionnalités sont utilisables uniquement avec les personal access tokens (classic) :

• Seuls les personal access tokens (classic) disposent d’un accès en écriture pour les dépôts publics qui ne vous appartiennent pas, ou qui appartiennent à une organisation dont vous n’êtes pas membre.
• Seuls les personal access tokens (classic) disposent automatiquement d’un accès en écriture pour les dépôts internes qui appartiennent à votre entreprise. Les Fine-grained personal access token doivent disposer d’un accès aux dépôts internes.
• Les collaborateurs externes peuvent utiliser uniquement les personal access tokens (classic) pour accéder aux dépôts d’organisation dont ils sont collaborateurs.
• Seuls les personal access tokens (classic) peuvent accéder aux entreprises. (Un Fine-grained personal access token peut accéder aux organisations appartenant aux entreprises).
• Seuls quelques points de terminaison d’API REST sont disponibles uniquement avec personal access tokens (classic). Pour vérifier si un point de terminaison prend également en charge les jetons de type fine-grained personal access token, consultez la documentation de ce point de terminaison ou consultez Points de terminaison disponibles pour les jetons d’accès personnels affinés.

Si vous choisissez d’utiliser un personal access token (classic), gardez à l’esprit qu’il accordera l’accès à tous les référentiels au sein des organisations auxquelles vous avez accès, ainsi qu’à tous les référentiels personnels dans votre compte personnel.

Sécuriser vos personal access token

          Personal access tokens’apparentent à des mots de passe et partagent les mêmes risques de sécurité inhérents. Avant de créer un nouveau personal access token, envisagez s’il existe une méthode d’authentification plus sécurisée à votre disposition :

• Pour accéder à GitHub partir de la ligne de commande, vous pouvez utiliser GitHub CLI ou Git Credential Manager au lieu de créer un personal access token.
• Lorsqu'un personal access token est utilisé dans un flux de travail GitHub Actions, déterminez si vous pouvez utiliser le composant intégré GITHUB_TOKEN plutôt. Pour plus d’informations, consultez « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».

Si ces options ne sont pas possibles et que vous devez créer un service CLI, envisagez d’utiliser personal access tokenun autre service CLI pour stocker votre jeton en toute sécurité.

Lorsque vous utilisez un personal access token script, vous pouvez stocker votre jeton en tant que secret et exécuter votre script via GitHub Actions. Pour plus d’informations, consultez Utilisation de secrets dans GitHub Actions.

Pour plus d’informations sur les bonnes pratiques, consultez Sécuriser les informations d’identification de l’API.

Création d’un fine-grained personal access token

1. Dans le coin supérieur droit de n’importe quelle page sur GitHub, cliquez sur votre photo de profil, puis sur Paramètres.

2. Dans la barre latérale gauche, cliquez sur Paramètres de développeur.

3. Dans la barre latérale gauche, sous Personal access tokens, cliquez sur Jetons à grain fin.

4. Cliquez sur Générer un nouveau jeton.

5. Sous Nom du jeton, entrez un nom pour le jeton.

6. Sous Expiration, sélectionnez une date d’expiration pour le jeton. Les durées de vie illimitées sont autorisées, mais peuvent être bloquées par une politique de durée de vie maximale définie par votre organisation ou le propriétaire de l’entreprise. Pour plus d’informations, consultez Appliquer une stratégie de durée de vie maximale pour personal access tokens.

7. Le cas échéant, sous Description, ajoutez une note pour décrire la finalité du jeton.

8. Sous Propriétaire de ressource, sélectionnez un propriétaire de ressource. Le jeton peut uniquement accéder aux ressources appartenant au propriétaire de ressource sélectionné. Les organisations dont vous êtes membre n’apparaissent pas si l’organisation a bloqué l’utilisation de fine-grained personal access tokens. Pour plus d’informations, consultez Définition d’une stratégie de jeton d’accès personnel pour votre organisation.

9. Optionnellement, si le propriétaire de la ressource est une organisation qui nécessite une approbation pour fine-grained personal access tokens, saisissez une justification pour la requête dans la zone située sous le propriétaire de la ressource.

10. Sous Accès au dépôt, sélectionnez les dépôts auxquels vous souhaitez que le jeton accède. Vous devez choisir l’accès minimal au dépôt répondant à vos besoins. Les jetons incluent toujours l’accès en lecture seule à tous les dépôts publics sur GitHub.

11. Si vous avez sélectionné Sélectionner uniquement les dépôts à l’étape précédente, sous la liste déroulante Dépôts sélectionnés, sélectionnez les dépôts auxquels vous souhaitez que le jeton accède.

12. Sous Autorisations, sélectionnez les autorisations à octroyer au jeton. Selon les informations que vous avez spécifiées pour le propriétaire de la ressource et l’accès au dépôt, il existe des autorisations relatives au dépôt, à l’organisation et au compte. Vous devez choisir les autorisations minimales nécessaires à vos besoins.

    Le document de référence de l’API REST pour chaque point de terminaison indique si le point de terminaison fonctionne avec fine-grained personal access tokens et indique les autorisations requises pour que le jeton utilise le point de terminaison. Certains points de terminaison peuvent nécessiter plusieurs autorisations, et certains points de terminaison peuvent nécessiter une autorisation parmi des autorisations multiples. Pour obtenir une vue d’ensemble des points de terminaison de l’API REST auxquels un fine-grained personal access token accès peut être associé à chaque autorisation, consultez Autorisations nécessaires pour les jetons d’accès personnels affinés.

13. Cliquez sur Générer un jeton.

Si vous avez sélectionné une organisation en tant que propriétaire de la ressource et que l'organisation a besoin d'une approbation pour les fine-grained personal access tokens, alors votre jeton sera marqué comme pending jusqu'à ce qu'il soit examiné par un administrateur de l'organisation. Votre jeton ne peut pas lire les ressources publiques tant qu’il n’a pas été approuvé. Si vous êtes propriétaire de l’organisation, votre demande est automatiquement approuvée. Pour plus d’informations, consultez « Examen et révocation des jetons d’accès personnels dans votre organisation ».

Préremplation fine-grained personal access token des détails à l’aide des paramètres d’URL

Vous pouvez partager des modèles pour un fine-grained personal access token via des liens. Le stockage des informations relatives aux jetons de cette manière facilite l’automatisation des flux de travail et améliore l’expérience des développeurs en orientant les utilisateurs vers la création de jetons avec les champs pertinents déjà remplis.

Chaque champ pris en charge peut être défini à l’aide d’un paramètre de requête spécifique. Tous les paramètres sont facultatifs et validés par le formulaire de génération de jetons afin de garantir que les combinaisons d’autorisations et de propriétaires de ressources sont cohérentes.

Un exemple de modèle d’URL est présenté ci-dessous, avec des sauts de ligne pour plus de lisibilité :

https://github.com/settings/personal-access-tokens/new
  ?name=Repo-reading+token
  &description=Just+contents:read
  &target_name=octodemo
  &expires_in=45
  &contents=read

https://github.com/settings/personal-access-tokens/new
  ?name=Repo-reading+token
  &description=Just+contents:read
  &target_name=octodemo
  &expires_in=45
  &contents=read

Essayez l’URL pour créer un jeton avec contents:read et metadata:read, avec le nom et la description indiqués et une date d’expiration fixée à 45 jours dans le futur. Un message d’erreur indiquant Cannot find the specified resource owner: octodemo s’affichera, car vous n’êtes pas membre de l’organisation octodemo.

Vous trouverez ci-dessous quelques exemples d’URL qui génèrent les jetons que nous observons le plus fréquemment :

• Lire le contenu du référentiel
• Accès push aux référentiels
• Accès aux modèles GitHub
• Mettre à jour le code et ouvrez une PR
• Gérer les licences Copilot dans une organisation
• Faire des requêtes Copilot

Paramètres de requête pris en charge

Pour créer votre propre modèle de jeton, suivez les détails des paramètres de requête fournis dans ce tableau :

          `30` ou `none` | Nombre entier compris entre 1 et 366, ou `none` | Jours avant l’expiration ou `none` pour les produits sans date d’expiration. Si cette information n’est pas fournie, la valeur par défaut est de 30 jours, ou moins si la cible dispose d’une politique de durée de vie des jetons. |

| <permission> | string | contents=read | Une série de niveaux d’autorisation et d’accès. | Les autorisations que le jeton devrait posséder. Les autorisations peuvent être définies sur read, write ou admin, mais toutes les autorisations ne prennent pas en charge chacun de ces niveaux. |

Autorisations

Chaque autorisation prise en charge est définie à l’aide de son nom comme paramètre de requête, la valeur spécifiant le niveau d’accès souhaité. Les niveaux d’accès valides sont read, write et admin. Certaines autorisations ne prennent en charge que read, d’autres uniquement write, et seules quelques-unes prennent en charge admin. Utilisez autant d’autorisations que nécessaire, sous la forme &contents=read&pull_requests=write&....

Il n’est pas nécessaire d’inclure à la fois read et write pour une autorisation dans votre URL : write inclut toujours read, et admin inclut toujours write.

Autorisations du compte

Les autorisations de compte ne sont utilisées que lorsque l’utilisateur actuel est défini comme propriétaire de la ressource.

          `read`, `write` |

| codespaces_user_secrets | Secrets utilisateur Codespaces | read, write | | copilot_messages | Discussion avec Copilot | read | | copilot_editor_context | contexte d'édition de Copilot | read | | copilot_requests | demandes de Copilot | write | | emails | Adresses e-mail | read, write | | user_events | Événements | read | | followers | Adeptes | read, write | | gpg_keys | Clés GPG | read, write | | gists | Gists | write | | keys | Clés SSH Git | read, write | | interaction_limits | Limites d’interaction | read, write | | knowledge_bases | Bases de connaissances | read, write | | user_models | Modèles | read | | plan | Plan | read | | private_repository_invitations | Invitations à un référentiel privé | read | | profile | Profil | write | | git_signing_ssh_public_keys | Clés de signature SSH | read, write | | starring | Attribution d’étoiles | read, write | | watching | Visionnage | read, write |

Autorisations des référentiels

Les autorisations de référentiel s’appliquent à la fois aux utilisateurs et aux propriétaires de ressources d’organisation.

          `read`, `write` |

| administration | Administration | read, write | | | | attestations | Attestations | read, write | | | | security_events | Alertes d’analyse du code | read, write | | codespaces | Codespaces | read, write | | codespaces_lifecycle_admin | Administrateur de cycle de vie de codespaces | read, write | | codespaces_metadata | Métadonnées de codespaces | read | | codespaces_secrets | Secrets de codespaces | write | | statuses | États de validation | read, write | | contents | Contenus | read, write | | repository_custom_properties | Propriétés personnalisées | read, write | | vulnerability_alerts | Alertes Dependabot | read, write | | dependabot_secrets | Secrets Dependabot | read, write | | deployments | Déploiements | read, write | | discussions | Discussions | read, write | | environments | Environnements | read, write | | issues | Problèmes | read, write | | merge_queues | Fusionner les files d’attente | read, write | | metadata | Métadonnées | read | | pages | Pages | read, write | | pull_requests | Demandes de tirage | read, write | | repository_advisories | Avis de sécurité des dépôts | read, write | | secret_scanning_alerts | Alertes d’analyse de secrets | read, write | | secrets | Secrets | read, write | | actions_variables | Variables | read, write | | repository_hooks | Webhooks | read, write | | workflows | Workflows | write |

Autorisations des organisations

Les autorisations d’organisation ne peuvent être utilisées que si le propriétaire de la ressource est une organisation.

          `read`, `write` |

| organization_user_blocking | Blocage d’utilisateurs | read, write | | organization_campaigns | Campagnes | read, write | | organization_custom_org_roles | Rôles d’organisation personnalisés | read, write | | organization_custom_properties | Propriétés du référentiel personnalisé | read write admin | | organization_custom_roles | Rôles de dépôts personnalisés | read, write | | organization_events | Événements | read | | organization_copilot_seat_management | GitHub Copilot Business | read, write | | issue_types | Types de problème | read, write | | organization_knowledge_bases | Bases de connaissances | read, write | | members | Membres | read, write | | organization_models | Modèles | read | | organization_network_configurations | Configurations réseau | read, write | | organization_announcement_banners | Bannières d’annonce de l’organisation | read, write | | organization_codespaces | Codespaces de l’organisation | read, write | | organization_codespaces_secrets | Secrets des codespaces de l’organisation | read, write | | organization_codespaces_settings | Paramètres des codespaces de l’organisation | read, write | | organization_dependabot_secrets | Secrets Dependabot de l’organisation | read, write | | organization_code_scanning_dismissal_requests | Demandes de rejet par analyse de code | read, write | | organization_private_registries | Registres privés | read, write | | organization_plan | Plan | read | | organization_projects | Projets | read write admin | | organization_secrets | Secrets | read, write | | organization_self_hosted_runners | Exécuteurs auto-hébergés | read, write | | team_discussions | Discussions d’équipe | read, write | | organization_actions_variables | Variables | read, write | | organization_hooks | Webhooks | read, write |

Création d’un personal access token (classic)

1. Dans le coin supérieur droit de n’importe quelle page sur GitHub, cliquez sur votre photo de profil, puis sur Paramètres.

2. Dans la barre latérale gauche, cliquez sur Paramètres de développeur.

3. Dans la barre latérale gauche, sous Personal access tokens, cliquez sur Jetons (classique).

4. Sélectionnez Générer un nouveau jeton, puis cliquez sur Générer un nouveau jeton (classique).

5. Dans le champ « Note », donnez un nom descriptif à votre jeton.

6. Pour donner une expiration à votre jeton, sélectionnez Expiration, puis choisissez une option par défaut ou cliquez sur Personnalisé pour entrer une date.

7. Sélectionnez les étendues à octroyer à ce jeton. Pour utiliser votre jeton afin d’accéder aux dépôts à partir de la ligne de commande, sélectionnez dépôt. Un jeton sans étendues attribuées peut accéder aux informations publiques uniquement. Pour plus d’informations, consultez « Étendues des applications OAuth ».

8. Cliquez sur Générer un jeton.

9. Si vous le souhaitez, pour copier le nouveau jeton dans votre presse-papiers, cliquez sur .

          ![Capture d’écran de la page « Personal access tokens ». À côté d'un jeton estompé, une icône de deux carrés qui se chevauchent est surlignée en orange.](/assets/images/help/settings/personal-access-tokens-ghes.png)
   

Suppression d’un personal access token

Vous devez supprimer une personal access token si elle n’est plus nécessaire. Si vous supprimez un personal access token utilisé pour créer une clé de déploiement, cette clé de déploiement sera également supprimée.

1. Dans le coin supérieur droit de n’importe quelle page sur GitHub, cliquez sur votre photo de profil, puis sur Paramètres.

2. Dans la barre latérale gauche, cliquez sur Paramètres de développeur.

3. Dans la barre latérale gauche, sous Personal access tokens, cliquez sur jetons affinés ou jetons (classiques), en fonction du type de personal access token que vous souhaitez supprimer.

4. À droite de la personal access token, cliquez sur Supprimer.

Utilisation d’une personal access token ligne de commande

Une fois que vous avez un personal access token, vous pouvez l’entrer au lieu de votre mot de passe lors de l’exécution d’opérations Git sur HTTPS.

Par exemple, pour cloner un dépôt sur la ligne de commande, vous devez entrer la commande suivante git clone. Vous êtes alors invité à entrer votre nom d’utilisateur et votre mot de passe. Lorsque vous y êtes invité, entrez votre personal access token mot de passe au lieu d’un mot de passe.

$ git clone https://HOSTNAME/USERNAME/REPO.git
Username: YOUR-USERNAME
Password: YOUR-PERSONAL-ACCESS-TOKEN

Bien que vous deviez entrer votre nom d’utilisateur avec votre personal access tokennom d’utilisateur, le nom d’utilisateur n’est pas utilisé pour vous authentifier. Au lieu de cela, personal access token est utilisé pour vous authentifier. Si vous n’entrez pas de nom d’utilisateur, vous recevrez un message d’erreur indiquant que vos identifiants ne sont pas valides.

          Personal access tokenne peut être utilisé que pour les opérations Git HTTPS. Si votre dépôt utilise une URL distante SSH, vous devez [faire passer le dépôt distant de SSH à HTTPS](/get-started/git-basics/managing-remote-repositories#switching-remote-urls-from-ssh-to-https).

Si vous n’êtes pas invité à entrer votre nom d’utilisateur et votre mot de passe, il se peut que vos informations d’identification soient en cache sur votre ordinateur. Vous pouvez mettre à jour vos informations d’identification dans le trousseau pour remplacer votre ancien mot de passe par le jeton.

Au lieu d’entrer manuellement votre personal access token pour chaque opération Git HTTPS, vous pouvez mettre en cache votre personal access token avec un client Git. Git stocke temporairement vos informations d’identification en mémoire jusqu’à ce qu’un intervalle d’expiration soit écoulé. Vous pouvez également stocker le jeton dans un fichier texte brut que Git peut lire avant chaque requête. Pour plus d’informations, consultez « Mise en cache de vos informations d’identification GitHub dans Git ».

Pour aller plus loin

• À propos de l’authentification à GitHub
• Expiration et révocation des jetons