Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-09-25. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Authentification auprès d’une application GitHub pour le compte d’un utilisateur

Votre application GitHub peut effectuer des actions pour le compte d’un utilisateur, comme créer un problème, poster un commentaire ou créer un déploiement.

Votre application peut effectuer des requêtes d’API pour le compte d’un utilisateur. Les demandes d’API effectuées par une application pour le compte d’un utilisateur seront attribuées à cet utilisateur. Par exemple, si votre application publie un commentaire pour le compte d’un utilisateur, l’interface utilisateur GitHub affiche la photo de l’avatar de l’utilisateur ainsi que le badge d’identification de l’application en tant qu’auteur du problème.

Capture d’écran d’un commentaire qui a un avatar utilisateur avec un badge d’identicon d’application superposé. L’avatar est mis en évidence avec un encadré orange.

De même, si la demande déclenche une entrée correspondante dans les journaux d’audit et les journaux de sécurité, les journaux répertorient l’utilisateur en tant qu’acteur, mais indiquent que « programmatic_access_type » est « GitHub App user-to-server token ».

Pour effectuer une demande d’API pour le compte d’un utilisateur, celui-ci doit autoriser votre application. Si une application est installée sur une organisation qui comprend plusieurs membres, chaque membre doit autoriser l’application avant que celle-ci puisse agir en leur nom. Une application n’a pas besoin d’être installée pour qu’un utilisateur autorise l’application.

Lorsqu’un utilisateur installe une application sur son compte ou son organisation, il accorde à l’application l’autorisation d’accéder aux ressources de l’organisation et du dépôt qu’il a demandées. Pendant le processus d’installation, l’utilisateur voit également une liste d’autorisations utilisateur que l’application peut demander pour des utilisateurs individuels. Quand un utilisateur autorise une application, il lui accorde l’autorisation d’agir en son nom et il accorde les autorisations de compte demandées par l’application.

Une fois qu’un utilisateur a autorisé votre application, vous pouvez générer un jeton d’accès utilisateur, qui est un type de jeton OAuth. Vous devez envoyer le jeton d’accès utilisateur dans l’en-tête Authorization de vos demandes d’API suivantes. Pour plus d’informations sur l’invite d’un utilisateur à autoriser votre application et la génération d’un jeton d’accès utilisateur, consultez « Génération d’un jeton d’accès utilisateur pour une application GitHub ».

Les requêtes effectuées avec un jeton d’accès utilisateur sont parfois appelées requêtes « utilisateur à serveur ».

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.

Si vous souhaitez attribuer l’activité de l’application à l’application plutôt qu’à un utilisateur, vous devez plutôt vous authentifier en tant qu’installation d’application. Pour plus d’informations, consultez « Installation de l’authentification en tant qu’application GitHub ».

Note

Si un utilisateur signale qu’il ne peut pas voir les ressources appartenant à son organisation après avoir autorisé votre GitHub App et que l’organisation utilise l’authentification unique SAML, demandez à l’utilisateur de démarrer une session SAML active pour son organisation avant de réautoriser. Pour plus d’informations, consultez  »Applications SAML et GitHub » dans la documentation GitHub Enterprise Cloud.