Que sont les applications GitHub ?

Effectué

Nous décrivons ici les applications GitHub, leur fonctionnement et comment vous pouvez les utiliser pour améliorer vos workflows. Que vous adoptiez une solution créée par quelqu’un d’autre ou que vous en développiez une pour répondre à vos besoins précis, il est toujours possible d’améliorer vos processus.

Étendre la plateforme par le biais de l’API GitHub

GitHub fournit une API robuste qui permet aux développeurs d’effectuer quasiment n’importe quoi sur la plateforme. Comme elle est exposée par le biais de points de terminaison REST, il est facile de l’intégrer à partir de n’importe quel langage de programmation ou plateforme. Cependant, l’accès à l’API ne se suffit pas à lui-même. Les développeurs souhaitant partager leurs fonctionnalités avec d’autres doivent néanmoins toujours les empaqueter en tant qu’application et les publier avant que quiconque ne puisse les utiliser.

Plusieurs facteurs sont à prendre en compte pour choisir d’incorporer une application OAuth ou une application GitHub dans votre workflow. Dans cette section, nous allons découvrir les applications GitHub et les applications OAuth, leurs différences en termes d’utilisation et d’autorisation, ainsi que leurs abonnements aux événements.

Quand vous personnalisez un workflow GitHub, plusieurs fonctionnalités sont disponibles, notamment l’écriture de scripts personnalisés, la création et l’autorisation de vos propres applications OAuth, ou l’installation d’applications GitHub disponibles à partir de GitHub Marketplace. En général, vous pouvez utiliser des scripts pour ces tâches ponctuelles. Pour des actions à exécuter plus souvent, vous pouvez utiliser l’automatisation des applications OAuth et GitHub pour vous aider, vous et votre équipe, à gagner du temps et à conserver un niveau de sécurité optimal au sein de vos workflows. Il existe de nombreuses différences qui influencent votre choix d’utiliser une application GitHub ou une application OAuth. La compréhension de ces différences en amont peut vous simplifier la vie par la suite et vous aider à trouver l’application la mieux adaptée à votre cas d’usage particulier au sein de votre workflow.

À la fin de cette section, vous aurez acquis une bonne compréhension des différences entre une application GitHub et une application OAuth et vous saurez laquelle choisir dans toutes les situations.

Octroi de l’accès et des autorisations

Les autorisations dont une application a besoin pour fonctionner constituent l’un des éléments les plus importants à prendre en compte pour lui permettre d’accéder à un dépôt GitHub. Il est facile d’accorder sa confiance à certaines applications, mais d’autres peuvent être suspectes. Veillez à toujours vérifier que les autorisations que vous accordez à une application vous conviennent.

Notes

Chaque application utilise une clé API unique pour demander des données dans votre dépôt. Lorsque vous autorisez l’accès, c’est la clé que vous autorisez. Vous pouvez révoquer l’accès à la clé d’une application à tout moment à partir des paramètres de votre dépôt.

applications OAuth

Les applications OAuth offrent un moyen d’accéder à des données GitHub au nom d’un utilisateur. Étant donné qu’elles agissent au nom de l’utilisateur, il est important de noter qu’un siège sous licence GitHub est alors consommé. Vous pouvez créer et inscrire une application OAuth dans votre compte personnel ou au niveau de l’organisation si vous disposez d’un accès administratif. Une application OAuth qui s’intègre à GitHub indique le type d’accès à l’organisation ou au dépôt nécessaire. Les utilisateurs autorisent les applications OAuth, ce qui donne à l’application la capacité d’agir en tant qu’utilisateur authentifié, notamment pour lire ou modifier des données. Cette approche est essentiellement un moyen automatisé de lire, écrire ou modifier des données GitHub en tant qu’utilisateur. Il est également important de noter que l’autorisation est limitée aux ressources accessibles à l’utilisateur. En revanche, l’application OAuth obtient aussi l’accès à toutes les ressources disponibles pour l’utilisateur.

Notes

Le niveau d’accès est limité par l’étendue du jeton (utilisateur, organisation, dépôt).

Pour les organisations soumises à des restrictions d’accès aux applications OAuth, l’administrateur est capable d’approuver l’utilisation de l’application. Avec des abonnements aux événements, les applications OAuth répondent à l’activité dès qu’elle se produit.

Applications GitHub

Par opposition, les applications GitHub sont installées dans votre compte personnel, dans les organisations que vous possédez ou dans des dépôts spécifiques auxquels vous avez accès en tant qu’administrateur. Les applications GitHub sont installées et interagissent avec GitHub en tant que service, et non en tant qu’utilisateur individuel comme c’est le cas avec les applications OAuth. Contrairement aux applications OAuth, l’avantage est que les applications GitHub ne consomment pas de siège sous licence GitHub.

Les applications GitHub accèdent aux données au nom de l’application elle-même via une clé privée utilisée pour signer un jeton JWT (JSON Web Token). Comme elles sont installées sur des dépôts spécifiques, les utilisateurs peuvent choisir les dépôts auxquels l’application peut accéder, ce qui limite la quantité de données auxquelles l’application peut accéder. Les autorisations définissent les ressources auxquelles l’application GitHub peut accéder par le biais de l’API. Contrairement aux applications OAuth, les applications GitHub ont des autorisations d’accès personnalisables pour les données, les problèmes et les demandes de tirage des dépôts. Ainsi, vous pouvez affiner l’octroi des autorisations, en limitant l’application à la lecture et l’écriture dans les seuls dépôts auxquels elle est autorisée à accéder. Seuls les propriétaires de l’organisation peuvent gérer la configuration des applications GitHub dans une organisation.

Vous pouvez trouver et installer GitHub Apps sur la Place de marché GitHub. Quand vous recherchez des applications GitHub, gardez à l’esprit que certaines applications ont un badge vérifié. Ce badge indique que l’application appartient à une organisation qui a vérifié la propriété de son domaine,qui a confirmé ses adresses e-mail auprès du support GitHub et qui nécessite une authentification à 2 facteurs pour son organisation.

• Un administrateur peut accorder des autorisations liées à l’administration des dépôts, aux vérifications, au contenu des dépôts, aux déploiements et aux problèmes. (Les modifications apportées par l’administrateur nécessitent leur acceptation par l’utilisateur.)
• Un administrateur peut accorder aux utilisateurs de l’application des autorisations qui leur permettent de bloquer un autre utilisateur, des e-mails, des abonnés, des clés GPG, des clés SSH Git, des participants spéciaux et des observateurs. (Les modifications apportées par l’administrateur nécessitent leur acceptation par l’utilisateur.)
• Abonnements aux événements : avis de sécurité, suite de vérification, création, déploiement, duplication (fork), étiquette, membre, archivage, commentaire de commit, suppression, état du déploiement, jalon, appartenance, organisation. (L’administrateur configure dans l’interface utilisateur de l’application GitHub et peut apporter des modifications.)

Choisir entre des applications GitHub et des applications OAuth

Même si les applications GitHub s’avèrent idéales pour une intégration à votre workflow dans certaines situations, il peut sembler difficile aux grandes organisations d’effectuer une transition de l’utilisation traditionnelle des applications OAuth vers une automatisation. Par exemple, une restriction de stratégie de sécurité peut également limiter les options d’un administrateur quant au choix d’utiliser ces outils.

Notes

En tant qu’administrateur système, vous devez collaborer avec vos développeurs pour déterminer les options les mieux adaptées à l’automatisation en tirant parti de ces applications tout en respectant votre stratégie de sécurité.

Pour déterminer quelle application est la solution la mieux adaptée à votre situation, voici quelques questions importantes à se poser :

• Est-ce que je veux que l’application agisse en tant qu’utilisateur ?
• Quels seront les besoins en termes de limite de débit ?
• Quel accès l’application doit-elle avoir dans l’organisation et les dépôts ?
• Cette application se conforme-t-elle à notre stratégie de sécurité ?

Voici les principales caractéristiques et différences à prendre en compte pour faire le choix d’une application GitHub ou d’une application OAuth.

Applications GitHub	applications OAuth
L’installation d’une application GitHub lui octroie l’accès aux référentiels choisis d’un compte d’utilisateur ou d’organisation.	L’autorisation d’une application OAuth permet à l’application d’accéder aux ressources accessibles de l’utilisateur, par exemple aux référentiels auxquels il peut accéder.
Les jetons d’accès d’installation sont limités aux dépôts spécifiés avec les autorisations choisies par le créateur de l’application.	Un jeton d’accès OAuth est limité par le biais d’étendues.
Un jeton d’installation identifie l’application en tant que bot des applications GitHub.	Un jeton d’accès identifie l’application en tant qu’utilisateur qui a accordé le jeton à l’application.
Les applications GitHub ont des autorisations ciblées qui leur permettent de demander l’accès à uniquement ce dont elles ont besoin.	Les applications OAuth ne peuvent pas utiliser des autorisations précises.
Les applications GitHub ne sont pas soumises aux stratégies d’application de l’organisation. Une application GitHub a uniquement accès aux dépôts auxquels le propriétaire d’une organisation a accordé cet accès.	Si une stratégie d’application d’organisation est active, seul le propriétaire d’une organisation peut autoriser l’installation d’une application OAuth. Si elle est installés, l’application OAuth obtient l’accès à tout ce qui est visible par le jeton que détient le propriétaire de l’organisation au sein de l’organisation approuvée.
Des augmentations de limite de débit peuvent être accordées au niveau des applications GitHub (ce qui affecte toutes les installations) et au niveau de l’installation individuelle.	Les augmentations de limite de débit sont accordées par application OAuth. Chaque jeton accordé à cette application OAuth obtient la limite accrue.
Les applications GitHub peuvent s’authentifier au nom de l’utilisateur, ce qui correspond à des demandes utilisateur à serveur. Le flux d’autorisation est le même que celui d’une application OAuth. Les jetons utilisateur à serveur peuvent expirer et être renouvelés avec un jeton d’actualisation.	Le flux OAuth utilisé par les applications OAuth autorise une application OAuth au nom de l’utilisateur. Ce même flux est utilisé dans le cadre d’une autorisation utilisateur à serveur d’application GitHub.
Les applications GitHub demandent l’autorisation d’accéder au contenu des dépôts et d’utiliser votre jeton d’installation pour s’authentifier par le biais de Git basé sur HTTP.	Les applications OAuth demandent l’étendue write:public_key et créent une clé de déploiement par le biais de l’API. Vous pouvez ensuite utiliser cette clé pour exécuter des commandes Git.

Accès aux applications et autorisations

Les autorisations dont une application a besoin pour fonctionner constituent l’un des éléments les plus importants à prendre en compte pour lui permettre d’accéder à un dépôt GitHub. Il est facile d’accorder sa confiance à certaines applications, mais d’autres peuvent être suspectes. Veillez à toujours vérifier que les autorisations que vous accordez à une application vous conviennent.

Prendre la décision d’utiliser une application GitHub ou une application OAuth peut dépendre du niveau d’accès que vous voulez pour l’application. En règle générale, il est préférable d’encourager votre équipe à utiliser l’outil avec la plus petite étendue pour accomplir la tâche. Une application OAuth a accès à toutes les ressources du propriétaire de l’organisation ou de l’utilisateur.

• Les applications OAuth peuvent avoir un accès en lecture ou en écriture à vos données GitHub.
• Une application GitHub peut se voir accorder l’accès à un seul compte

Sécurité des applications

Quand une vulnérabilité est détectée dans votre application, elle doit constituer une priorité et votre stratégie de sécurité doit en informer les utilisateurs de votre projet. La communication rapide d’un problème de sécurité peut faire la différence : vos utilisateurs sont alors en mesure de révoquer un jeton compromis, sans quoi leurs données sensibles courent le risque d’être exposées. Même si les jetons sont bien plus sûrs que les mots de passe, la sécurité peut quand même être compromise et il est important que votre organisation y soit préparée.

En plus d’un fichier README.md, nous vous recommandons d’ajouter un fichier SECURITY.md à vos dépôts. Ce fichier SECURITY.md met l’accent sur les informations relatives à la sécurité du dépôt. Il doit inclure les contacts en charge de la sécurité, les stratégies de votre organisation et décrire la réponse que vous allez apporter en cas de détection d’une vulnérabilité.

Réponse aux événements

Les applications GitHub sont conçues pour être passives. Elles attendent qu’un événement se produise, puis réagissent, généralement par le biais de l’API GitHub. Lorsque vous attendez que des événements se produisent sur GitHub, il existe deux approches : les webhooks et l’interrogation.

Notes

Les applications GitHub ne sont pas limitées à l’utilisation des données GitHub. Vous pouvez tout aussi facilement attendre des événements qui se produisent depuis d’autres sources ou exécuter des actions qui mettent à jour d’autres services.

Utilisation des webhooks GitHub

Les webhooks constituent l’approche privilégiée pour la gestion des événements. Quand un événement se produit sur GitHub dans l’étendue d’un webhook, il est immédiatement déclenché. Les webhooks envoient (push) des notifications que votre application peut écouter et traiter en temps réel. Vous pouvez configurer des webhooks dans les paramètres de votre dépôt, notamment les types d’événements, l’authentification et la façon dont les notifications HTTP sont remises.

Interrogation

Parfois, les webhooks ne sont pas à envisager. Votre application peut avoir besoin de se trouver derrière un pare-feu d’entreprise où GitHub ne peut pas l’atteindre directement. Dans ce cas, une alternative consiste à interroger les données que vous suivez à l’aide de l’API GitHub.

Relais de webhooks

Une alternative à l’interrogation des applications derrière un pare-feu consiste à utiliser un service de transfert de webhooks, comme smee.io. Avec cette approche, le service public s’abonne au webhook du dépôt et relaie les données entrantes vers un service client s’exécutant derrière le pare-feu. Ce service client envoie ensuite les notifications à votre application en cours d’exécution comme si elles provenaient de la source d’origine.