Utilisation d’une GitHub App au lieu d’une OAuth app
En général, les GitHub Apps sont préférables aux OAuth apps.
GitHub Apps et OAuth apps utilisent OAuth 2.0.
Les OAuth apps peuvent agir uniquement pour le compte d’un utilisateur, tandis que les GitHub Apps peuvent agir pour le compte d’un utilisateur ou indépendamment d’un utilisateur.
Pour plus d’informations, consultez « Différences entre les applications GitHub et les applications OAuth ».
Pour plus d’informations sur la migration d’une OAuth app existante vers une GitHub App, consultez « Migration d’applications OAuth vers des applications GitHub ».
Les GitHub Apps offrent une sécurité renforcée
Les GitHub Apps offrent un plus grand contrôle sur ce que l’application peut faire. Au lieu des vastes étendues qu’utilisent les OAuth apps, les GitHub Apps utilisent des autorisations de granularité fine. Par exemple, si votre application doit lire le contenu d’un dépôt, une OAuth app nécessite l’étendue repo, qui lui permet également de modifier le contenu et les paramètres du dépôt. Une GitHub App peut demander un accès en lecture seule au contenu du dépôt, ce qui ne lui permet pas d’effectuer des actions plus privilégiées comme la modification du contenu ou des paramètres du dépôt.
Les GitHub Apps offrent également un plus grand contrôle sur l’accès aux référentiels. Avec une GitHub App, l’utilisateur ou le propriétaire de l’organisation qui a installé l’application peut décider des dépôts auxquels l’application peut accéder. À l’inverse, une OAuth app peut accéder à chaque dépôt auquel l’utilisateur qui a autorisé l’application peut accéder.
Les GitHub Apps utilisent des jetons de courte durée. Si le jeton est divulgué, il reste valide pendant un laps de temps plus court, ce qui réduit les dommages qui peuvent être causés. À l’inverse, les jetons d’OAuth app n’expirent pas tant que la personne qui a autorisé l’OAuth app n’a pas révoqué le jeton.
Ces fonctionnalités de sécurité permettent de durcir la sécurité de votre GitHub App en limitant les dommages qui pourraient être causés si les informations d’identification de votre application fuitaient. De plus, cela permet aux organisations avec des stratégies de sécurité plus strictes d’utiliser votre application.
Les GitHub Apps peuvent agir indépendamment d’un utilisateur ou au nom de celui-ci
Les GitHub Apps peuvent agir indépendamment d’un utilisateur. C’est bien pour les automatisations qui ne nécessitent pas d’entrée utilisateur.
Comme les OAuth apps, les GitHub Apps peuvent toujours effectuer des actions au nom d’un utilisateur. Contrairement aux OAuth apps, qui n’indiquent pas que l’action a été effectuée par l’application, les GitHub Apps indiquent que l’action a été effectuée par l’application au nom de l’utilisateur.
Les GitHub Apps ne sont pas liées à un compte d’utilisateur et ne consomment pas de siège sur GitHub Enterprise Server. Les GitHub Apps restent installées même lorsque la personne qui les a initialement installées quitte l’organisation. Cela permet à vos intégrations de continuer à fonctionner même si des personnes quittent votre équipe.
Les GitHub Apps ont des limites de débit évolutives
La limite de débit pour les GitHub Apps utilisant un jeton d’accès d’installation s’adapte au nombre de référentiels et au nombre d’utilisateurs dans l’organisation. À l’inverse, les OAuth apps ont des limites de débit inférieures et ne sont pas évolutives. Pour plus d’informations, consultez « Limites de débit pour les applications GitHub ».
Les GitHub Apps ont des webhooks intégrés
Les GitHub Apps ont des webhooks intégrés centralisés. Les GitHub Apps peuvent recevoir des événements de webhook pour l’ensemble des référentiels et des organisations auxquels l’application a accès. À l’inverse, les OAuth apps doivent configurer des webhooks individuellement pour chaque référentiel et chaque organisation.
L’accès aux API diffère légèrement
En général, les GitHub Apps et les OAuth apps peuvent effectuer les mêmes demandes d’API. Toutefois, il existe certaines différences entre ces deux éléments :
- L’API REST pour gérer les exécutions et les suites de vérifications est disponible dans les GitHub Apps uniquement.
- Les ressources de niveau entreprise telles que l’objet d’entreprise lui-même ne sont pas disponibles pour les GitHub Apps. Cela signifie que les GitHub Apps ne peuvent pas appeler de points de terminaison tels que
GET /enterprise/settings/license. Toutefois, les ressources d’organisation et de dépôt appartenant à l’entreprise sont disponibles. - Certaines demandes peuvent retourner des données incomplètes en fonction des autorisations et de l’accès au dépôt accordé à une GitHub App. Par exemple, si votre application effectue une demande pour obtenir tous les dépôts auxquels un utilisateur peut accéder, la réponse inclut uniquement les dépôts auxquels l’application a également obtenu l’accès.
Pour plus d’informations sur les points de terminaison d’API REST disponibles pour les GitHub Apps, consultez « Points de terminaison disponibles pour les jetons d’accès d’installation d’application GitHub ».
Choix entre une GitHub App ou un personal access token
Si vous souhaitez accéder aux ressources GitHub au nom d’un utilisateur ou dans une organisation, ou si vous prévoyez une intégration longue durée, nous vous recommandons de créer une GitHub App.
Vous pouvez utiliser des personal access tokens pour les tests d’API ou les scripts de courte durée. Étant donné qu’un personal access token est associé à un utilisateur, votre automatisation peut s’interrompre si l’utilisateur n’a plus accès aux ressources dont vous avez besoin. Une GitHub App installée dans une organisation ne dépend pas d’un utilisateur. De plus, contrairement à un utilisateur, une GitHub App ne consomme pas de siège GitHub.
GitHub prend en charge deux types de personal access tokens, mais vous recommande d’utiliser des fine-grained personal access token à la place de personal access tokens autant que possible. Pour plus d’informations sur les personal access tokens, consultez « Gestion de vos jetons d'accès personnels ».
Choix entre une GitHub App ou des GitHub Actions
Les GitHub Apps et les GitHub Actions fournissent des moyens de créer des outils d’automatisation et de workflow.
Les GitHub Actions fournissent une automatisation pouvant effectuer des travaux telles que l’intégration continue, des tâches de déploiement et la gestion de projet dans un dépôt. Elles s’exécutent directement sur des machines d’exécuteur hébergé par GitHubou les exécuteurs auto-hébergés que votre administrateur configure. Les GitHub Actions ne s’exécutent pas de manière permanente. Les workflows GitHub Actions s’exécutent en réponse aux événements qui se produisent dans leur dépôt et n’ont accès qu’aux ressources du dépôt pour lequel ils sont configurés. Toutefois, des actions personnalisées peuvent être partagées entre les dépôts et les organisations, ce qui permet aux développeurs de réutiliser et de modifier les actions existantes pour répondre à leurs besoins. Les GitHub Actions sont également fournies avec une gestion des secrets intégrée, que vous pouvez utiliser pour interagir avec des services tiers et gérer les clés de déploiement, le tout de façon sécurisée.
Les GitHub Apps s’exécutent de manière permanente sur un serveur ou une infrastructure de calcul que vous fournissez ou exécutez sur un appareil utilisateur. Elles peuvent réagir aux événements de webhook GitHub ainsi qu’aux événements extérieurs à l’écosystème GitHub. Elles constituent une bonne option pour les opérations qui s’étendent sur plusieurs dépôts ou organisations, ou pour fournir des services hébergés à d’autres organisations. Une GitHub App est le meilleur choix pour créer un outil avec des fonctions qui se produisent principalement en dehors de GitHub ou qui demandent plus de temps d’exécution ou d’autorisations que quand un workflow GitHub Actions est alloué.
Pour plus d’informations sur la comparaison entre les GitHub Actions et les GitHub Apps, consultez « À propos des actions personnalisées ».
Vous pouvez utiliser une GitHub App pour vous authentifier dans un workflow GitHub Actions si le GITHUB_TOKEN intégré n’a pas d’autorisations suffisantes. Pour plus d’informations, consultez « Effectuer des requêtes d’API authentifiées avec une application GitHub dans un workflow GitHub Actions ».