Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Étendues des applications OAuth

Les étendues vous permettent de spécifier exactement le type d’accès dont vous avez besoin. Les étendues limitent l’accès des jetons OAuth. Elles n’accordent pas d’autorisation supplémentaire au-delà de celle que l’utilisateur a déjà.

Durant la configuration d’une application OAuth sur GitHub, l’utilisateur voit s’afficher les étendues demandées dans le formulaire d’autorisation.

Remarque : Si vous créez une application GitHub, vous n’avez pas besoin de fournir d’étendues dans votre demande d’autorisation. Pour plus d’informations, consultez « Identification et autorisation des utilisateurs pour les applications GitHub ».

Si votre OAuth App n’a pas accès à un navigateur (dans le cas d’un outil CLI, par exemple), vous n’avez pas besoin de spécifier d’étendue pour permettre aux utilisateurs de s’authentifier auprès de votre application. Pour plus d’informations, consultez « Autorisation des applications OAuth ».

Vérifiez les en-têtes pour voir vos étendues OAuth et ce qui est accepté par l’action d’API :

$ curl -H "Authorization: Bearer OAUTH-TOKEN" https://api.github.com/users/codertocat -I
HTTP/2 200
X-OAuth-Scopes: repo, user
X-Accepted-OAuth-Scopes: user
  • X-OAuth-Scopes liste les étendues autorisées par votre jeton.
  • X-Accepted-OAuth-Scopes liste les étendues vérifiées par l’action.

Étendues disponibles

Nom | Description -----|-----------| (no scope) | Octroie l’accès en lecture seule aux informations publiques (notamment les informations de profil utilisateur, les informations de dépôt et les gists) repo | Octroie l’accès total aux dépôts publics, internes et privés, notamment l’accès en lecture/écriture au code, aux états des commits, aux invitations de dépôt, aux collaborateurs, aux états des déploiements et aux webhooks de dépôt. Remarque : En plus des ressources associées au dépôt, l’étendue repo accorde également l’accès à la gestion des ressources appartenant à l’organisation, notamment les projets, les invitations, les appartenances aux équipes et les webhooks. Cette étendue accorde également la possibilité de gérer des projets appartenant aux utilisateurs.  repo:status| Octroie l’accès en lecture/écriture aux états de commit dans les dépôts publics, privés et internes. Cette étendue est nécessaire uniquement pour octroyer à d’autres utilisateurs ou services l’accès aux états de commit des dépôts privés sans octroyer l’accès au code.  repo_deployment| Octroie l’accès aux états de déploiement pour les dépôts publics et privés. Cette étendue est nécessaire uniquement pour octroyer à d’autres utilisateurs ou services l’accès aux états de déploiement, sans octroyer l’accès au code.  public_repo| Limite l’accès aux dépôts publics. Cela inclut l’accès en lecture/écriture au code, les états de commit, les projets de dépôt, les collaborateurs ainsi que les états de déploiement pour les dépôts publics et les organisations. Également nécessaire pour les dépôts publics favoris.  repo:invite | Octroie les capacités d’acceptation/de refus des invitations pour collaborer sur un dépôt. Cette étendue est nécessaire uniquement pour octroyer à d’autres utilisateurs ou services l’accès aux invitations sans octroyer l’accès au code.  security_events | Octroie :
Un accès en lecture et en écriture aux événements de sécurité dans l’API code scanning
Un accès en lecture et en écriture aux événements de sécurité dans l’API secret scanning
Cette étendue est nécessaire uniquement pour octroyer à d’autres utilisateurs ou services l’accès aux événements de sécurité sans octroyer l’accès au code. admin:repo_hook | Octroie l’accès en lecture, en écriture, en exécution de commande ping et en suppression aux crochets dans les dépôt publics, privés ou internes. L’étendue repo et l’étendue public_repo octroient un accès total aux dépôts, notamment les crochets de dépôt. Utilisez l’étendue admin:repo_hook pour limiter l’accès aux crochets de dépôt uniquement.  write:repo_hook | Octroie l’accès en lecture, en écriture et en exécution de commande ping aux crochets dans les dépôts publics, privés ou internes.  read:repo_hook | Octroie l’accès en lecture et en exécution de commande ping aux crochets dans les dépôts publics, privés ou internes. admin:org | Permet de gérer complètement l’organisation ainsi que ses équipes, ses projets et ses appartenances.  write:org| Permet d’accéder en lecture et en écriture à l’appartenance à l’organisation, aux projets d’organisation et à l’appartenance à une équipe.  read:org| Permet d’accéder en lecture uniquement à l’appartenance à l’organisation, aux projets d’organisation et à l’appartenance à une équipe. admin:public_key | Permet de gérer complètement les clés publiques.  write:public_key| Permet de créer, de lister et de voir les détails des clés publiques.  read:public_key| Permet de lister et de voir les détails des clés publiques. admin:org_hook | Octroie l’accès en lecture, en écriture, en exécution de commande ping et en suppression aux crochets d’organisation. Remarque : Les jetons OAuth ne peuvent effectuer ces actions que sur les crochets d’organisation créés par l’application OAuth. Les Personal access token ne peuvent effectuer ces actions que sur les crochets d’organisation créés par un utilisateur. gist | Octroie l’accès en écriture aux Gists. notifications | Octroie :
Un accès en lecture aux notifications d’un utilisateur
Un accès au marquage des threads comme étant lus
Un accès à l’activation/la désactivation de la surveillance d’un dépôt
Un accès en lecture, en écriture et en suppression aux abonnements aux threads. user | Octroie l’accès en lecture/écriture aux informations de profil uniquement. Notez que cette étendue comprend user:email et user:follow.  read:user| Octroie l’accès en lecture aux données de profil d’un utilisateur.  user:email| Octroie l’accès en lecture aux adresses e-mail d’un utilisateur.  user:follow| Octroie l’accès pour suivre ou ne plus suivre d’autres utilisateurs. project | Octroie l’accès en lecture/écriture aux projects d’utilisateur et d’organisation.  read:project| Octroie l’accès en lecture seule aux projects d’utilisateur et d’organisation. delete_repo | Octroie l’accès aux dépôts administrables supprimés. write:discussion | Octroie l’accès en lecture et en écriture aux discussions d’équipe.  read:discussion | Octroie l’accès en lecture aux discussions d’équipe. write:packages | Octroie l’accès nécessaire pour charger ou publier un package dans GitHub Packages. Pour plus d’informations, consultez « Publication d’un package ». read:packages | Octroie l’accès au téléchargement et à l’installation de packages à partir de GitHub Packages. Pour plus d’informations, consultez «  Installation d’un package ». delete:packages | Octroie l’accès à la suppression de packages à partir de GitHub Packages. Pour plus d’informations, consultez « Suppression et restauration d’un package ». admin:gpg_key | Gérez complètement les clés GPG.  write:gpg_key| Permet de créer, lister et voir les détails des clés GPG.  read:gpg_key| Permet de lister et de voir les détails des clés GPG. codespace | Permet de créer et de gérer des codespaces. Les codespaces peuvent exposer un GITHUB_TOKEN qui peut avoir un ensemble différent d’étendues. Pour plus d’informations, consultez « Sécurité dans GitHub Codespaces ». workflow | Permet d’ajouter et de mettre à jour les fichiers de workflow GitHub Actions. Les fichiers de workflow peuvent être commités sans cette étendue si le même fichier (avec le même chemin et le même contenu) existe dans une autre branche du même dépôt. Les fichiers de workflow peuvent exposer GITHUB_TOKEN, qui peut avoir un ensemble différent d’étendues. Pour plus d’informations, consultez « Authentification dans un workflow ». admin:enterprise | Donne un contrôle total sur le fonctionnement de l’entreprise. Pour plus d’informations, consultez « Gestion des comptes d’entreprise » dans la documentation de l’API GraphQL.

Inclut manage_runners:enterprise, manage_billing:enterprise, et read:enterprise.  manage_runners:enterprise | Donne un contrôle total sur les exécuteurs auto-hébergés au sein de l’entreprise. Pour plus d’informations, consultez « About self-hosted runners ».  manage_billing:enterprise | Lire et écrire des données de facturation d’entreprise Pour plus d’informations, consultez « Facturation » dans la documentation de l’API REST.  read:enterprise | Lire toutes les données d’un profil d’entreprise. N’inclut pas les données de profil des membres ou des organisations de l’entreprise. read:audit_log | Lire les données du journal d’audit.

Remarque : Votre application OAuth peut demander les étendues dans la redirection initiale. Vous pouvez spécifier plusieurs étendues en les séparant par un espace à l’aide de %20 :

https://github.com/login/oauth/authorize?
  client_id=...&
  scope=user%20repo_deployment

Étendues demandées et étendues octroyées

L’attribut scope liste les étendues attachées au jeton qui ont été octroyées par l’utilisateur. Normalement, ces étendues sont identiques à ce que vous avez demandé. Toutefois, les utilisateurs peuvent modifier leurs étendues, ce qui permet d’octroyer à votre application moins d’accès que ce que vous avez demandé à l’origine. De plus, les utilisateurs peuvent modifier les étendues des jetons, une fois le flux OAuth effectué. Vous devez être conscient de cette éventualité, et en tenir compte pour ajuster le comportement de votre application.

Il est important de gérer les cas d’erreur où un utilisateur choisit de vous octroyer un accès inférieur à celui que vous avez demandé à l’origine. Par exemple, les applications peuvent avertir les utilisateurs, ou leur indiquer qu’ils seront confrontés à des fonctionnalités réduites ou qu’ils ne pourront pas effectuer certaines actions.

De plus, les applications peuvent toujours renvoyer les utilisateurs dans le flux pour obtenir des autorisations supplémentaires. Toutefois, n’oubliez pas que les utilisateurs peuvent toujours dire non.

Consultez le Guide des informations de base sur l’authentification, qui fournit des conseils sur la gestion des étendues de jeton modifiables.

Étendues normalisées

Quand vous demandez plusieurs étendues, le jeton est enregistré avec une liste normalisée d’étendues, en écartant celles qui sont implicitement incluses par une autre étendue demandée. Par exemple, si vous demandez user,gist,user:email, vous obtenez un jeton avec les étendues user et gist uniquement, car l’accès octroyé avec l’étendue user:email est inclus dans l’étendue user.