Étendues des applications OAuth

Lors de la configuration d’un OAuth app sur GitHub, les étendues demandées sont affichées à l’utilisateur sur le formulaire d’autorisation.

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 ».

Consultez les en-têtes pour voir quels périmètres OAuth vous avez, et ce qui est accepté par l'action de l'API.

$ curl -H "Authorization: Bearer OAUTH-TOKEN" http(s)://HOSTNAME/api/v3/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

          **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 un accès en lecture et en écriture aux statuts de validation dans les référentiels 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| Accorde l’accès aux états de déploiement pour les dépôts publics et privés. Cette étendue n’est nécessaire que pour accorder à d’autres utilisateurs ou services l’accès aux états de déploiement, sans accorder l’accès au code.  public_repo| Limite l’accès aux référentiels 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. Requis également pour attribuer une étoile aux référentiels publics.  repo:invite | Autorise l’acceptation ou le refus des invitations à collaborer sur un référentiel. Cette étendue n’est nécessaire que pour accorder à d’autres utilisateurs ou services l’accès aux invitations sans accorder l’accès au code.  security_events | Subventions :
Un accès en lecture et en écriture aux événements de sécurité dans l’API code scanning
Cette étendue n’est nécessaire que pour accorder à d’autres utilisateurs ou services l’accès aux événements de sécurité sans accorder l’accès au code. admin:repo_hook | Autorise les opérations de lecture, d’écriture, de ping et de suppression sur les hooks des référentiels publics, privés ou internes. Les étendues repo et public_repo octroient un contrôle total sur les dépôts, y compris les hooks de dépôt. Utilisez l’étendue admin:repo_hook pour limiter l’accès uniquement aux hooks de dépôt.  write:repo_hook | Octroie des autorisations de lecture, d’écriture et de ping aux hooks des référentiels publics, privés ou internes.  read:repo_hook| Octroie des autorisations de lecture et de ping aux hooks des référentiels publics, privés ou internes. admin:org | Gérez complètement l’organisation et ses équipes, ses projets et ses membres.  write:org| Accès en lecture et en écriture aux membres de l'organisation et aux projets de l'organisation.  read:org| Permet d’accéder en lecture seule aux membres de l’organisation, aux projets de l’organisation et aux membres de l’équipe. admin:public_key | Permet de gérer entièrement les clés publiques.  write:public_key| Permet de créer, de lister et d’afficher les détails des clés publiques.  read:public_key| Permet de lister et d’afficher les détails des clés publiques. admin:org_hook | Octroie des autorisations de lecture, d’écriture, de ping et de suppression aux hooks de l’organisation. Remarque : Les jetons OAuth ne peuvent effectuer ces actions que sur les hooks d’organisation créés par l’OAuth app. Les Personal access token ne peuvent effectuer ces actions que sur les crochets d’organisation créés par un utilisateur. gist | Accorde un droit d’écriture sur les gists. notifications | Subventions :
Un accès en lecture aux notifications d’un utilisateur
Un accès au marquage des threads comme étant lus
Permet d’activer ou de désactiver la surveillance d’un référentiel, et
Un accès en lecture, en écriture et en suppression aux abonnements aux threads user | Accorde un accès en lecture/écriture aux seules informations du profil. Notez que cette étendue comprend user:email et user:follow.  read:user| Accorde l’accès à la lecture des données du profil d’un utilisateur.  user:email| Accorde un accès en lecture aux adresses e-mail d’un utilisateur.  user:follow| Accorde l’accès pour suivre ou ne plus suivre d’autres utilisateurs. delete_repo | Accorde l’accès pour supprimer les référentiels administrables. write:packages | Accorde l’accès au téléchargement ou à la publication d’un package dans GitHub Packages. Pour plus d’informations, consultez « Publication d'un package ». read:packages | Accorde 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 | Accorde 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 | Permet de gérer entièrement les clés GPG.  write:gpg_key| Permet de créer, lister et afficher les détails des clés GPG.  read:gpg_key| Permet de lister et d’afficher les détails des clés GPG. workflow | Permet d’ajouter et de mettre à jour les fichiers de flux de travail 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 de périmètres. Pour plus d’informations, consultez Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail. admin:enterprise | Donne un contrôle total des fonctionnalités d’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 | Permet un contrôle intégral des runners auto-hébergés à l’échelle de l’entreprise. Pour plus d’informations, consultez « Exécuteurs auto-hébergés ».  manage_billing:enterprise | Lisez et écrivez les données de facturation de l’entreprise. Pour plus d’informations, consultez « Points de terminaison d’API REST pour la facturation ».  read:enterprise | Lisez toutes les données d’un profil d’entreprise. Ne comprend pas les données de profil des membres de l'entreprise ou des organisations. read:audit_log | Lire les données du journal d'audit.

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 après la réalisation du flux OAuth. 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 principes de base de l'authentification, qui fournit des conseils sur la gestion des périmètres de jeton modifiables.

Étendues normalisées

Quand vous demandez plusieurs périmètres, le jeton est enregistré avec une liste de périmètres normalisée, excluant ceux qui sont implicitement inclus par un autre périmètre demandé. 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.