Identifier les jetons d’accès pris en charge

  • 8 minutes

Ici, vous découvrez les différents jetons d’accès GitHub, leurs applications, limitations et limites de débit.

Lorsque vous accordez l’accès aux utilisateurs au sein de votre entreprise, l’authentification est incroyablement importante. L’étendue de l’accès de l’utilisateur doit être précisément définie et seul ce qui lui est nécessaire pour faire son travail doit être inclus. Il est important de comprendre les différents jetons d’accès pour aider les utilisateurs au sein de l’entreprise à utiliser la meilleure option pour leurs cas d’usage.

GitHub utilise divers jetons qui permettent aux utilisateurs de s’authentifier pour les différentes activités qu’ils doivent effectuer. En règle générale, ces différents jetons sont simples et il est facile de savoir lequel utiliser. Mais parfois, plusieurs jetons peuvent être utilisés pour obtenir le même résultat : ainsi, choisir un jeton peut revenir à prendre une bonne décision, une meilleure décision et la meilleure décision. Dans ces situations, il est important d’identifier les caractéristiques des jetons GitHub et de savoir comment définir correctement l’étendue de l’accès d’un jeton. Voici une liste des différents jetons d’accès disponibles :

  • Jetons d’accès personnels GitHub
  • Jetons utilisateur à serveur GitHub
  • Jetons serveur à serveur GitHub
  • Jetons d’accès OAuth
  • Jetons d’actualisation

Il est important d’encourager votre équipe de développement à utiliser des jetons avec l’étendue appropriée pour que, en cas de détection d’une vulnérabilité de sécurité, le risque soit rapidement atténué. Intéressons-nous de plus près à chacun de ces jetons d’accès.

Jetons d’accès personnels

Un jeton d’accès personnel (PAT) est une alternative à l’utilisation d’un mot de passe pour l’authentification auprès de GitHub. Pour envoyer (push) et tirer (pull) dans des dépôts, GitHub a besoin de vérifier l’accès utilisateur. Cette vérification s’effectue par le biais de l’adresse e-mail vérifiée d’un utilisateur. Vous pouvez créer autant de jetons d’accès personnels que nécessaire pour votre workflow et les traiter de manière aussi sécurisée que des mots de passe. L’utilisation de différents jetons pour les différentes applications est une bonne pratique de sécurité. Pour créer un jeton d’accès personnel dans GitHub, vous accédez aux paramètres et, sous Paramètres du développeur, sélectionnez Jetons d’accès personnels.

Capture d’écran avec un exemple de jeton d’accès personnel GitHub.

Vous pouvez limiter l’étendue d’un jeton individuel pour autoriser uniquement l’accès requis pour l’authentification du travail auquel vous l’affectez. Le jeton est lié à un utilisateur spécifique et s’aligne sur l’accès de l’utilisateur à l’organisation et aux dépôts. Vous pouvez révoquer un jeton d’accès personnel à tout moment, ce qui est particulièrement important lorsqu’un problème de sécurité se produit. Il est important de faire savoir à votre équipe que les jetons d’accès personnels doivent être traités de manière aussi sécurisée qu’un nom d’utilisateur et un mot de passe. Si un jeton est compromis, une action immédiate doit être effectuée pour le révoquer.

Des étapes détaillées pour créer un jeton d’accès personnel sont disponibles ici : création d’un jeton d’accès personnel - GitHub Docs

Jetons d’appareil

Un jeton d’appareil est essentiellement une version de compte d’ordinateur d’un PAT, utilisée dans le contexte d’un appareil, qui donne accès à un référentiel spécifique dans des cas d’usage spécifiques qui ne sont pas liés à l’utilisateur. La configuration d’une application à l’aide d’un flux OAuth utilise un jeton d’appareil. Ils sont généralement utilisés avec des exécuteurs, des services d’application spéciaux, des travaux Cron (sous Linux) ou d’autres scénarios similaires liés aux tâches automatisées. Tout comme le jeton d’accès personnel, le jeton d’appareil est lié à un compte individuel et le compte pour lequel vous créez le jeton d’appareil consomme une licence.

Jetons d’installation d’application GitHub

Un jeton d’installation permet à une application GitHub d’effectuer des demandes d’API authentifiées pour l’installation de l’application dans une organisation. Avant de créer un jeton d’installation, vous devez d’abord installer l’application GitHub à laquelle le jeton s’applique, dans le référentiel de destination. Les jetons d’installation sont valides pendant une heure et sont sécurisés, car ils sont générés à des fins spécifiques et expirent dans un délai relativement court.

Jetons d’accès OAuth

Les jetons OAuth2 sont utilisés pour autoriser les utilisateurs pour des applications OAuth standard qui s’exécutent dans le navigateur, ainsi que pour des applications sans périphérique de contrôle comme les outils CLI. Ils permettent à votre application d’accéder à l’API avec un jeton d’accès utilisateur. Ces jetons vous permettent de connecter votre identité d’utilisateur GitHub à des applications tierces, ce qui permet aux applications d’effectuer des actions en votre nom. Par exemple, si vous souhaitez utiliser une application qui demande la portée user:email, l’application se voit attribuer un accès en lecture seule à vos adresses de messagerie privées. Ces jetons peuvent être acquis à l’aide du flux d’application web pour les applications de production. Étant donné que ces jetons sont à court terme et expirent en 10 minutes, ils sont également sécurisés.

Jetons d’actualisation

Un jeton d’actualisation est connecté à un jeton OAuth. Quand un nouveau jeton OAuth (par le biais d’une demande utilisateur à serveur) est accordé, un jeton d’actualisation est inclus dans la réponse. Quand le jeton utilisateur expire, le jeton d’actualisation peut être échangé contre un nouveau jeton utilisateur avec une demande de rappel. Chaque fois qu’un nouveau jeton OAuth est émis, un jeton d’actualisation est inclus. Les jetons d’actualisation sont valides pendant six mois et s’avèrent bien utiles pour ne pas oublier de mettre à jour vos jetons OAuth.

Préfixes identifiables

Comme nous le remarquons dans le secteur, les préfixes de jeton permettent de rendre les jetons clairement identifiables. GitHub inclut des préfixes à trois lettres pour représenter chaque jeton. Le préfixe commence par deux lettres qui signent la société, ghet est suivi de la première lettre du type de jeton. Les préfixes des types de jetons d’accès disponibles sont les suivants :

  • ghp pour les jetons d’accès personnels GitHub
  • ghu pour les jetons utilisateur à serveur GitHub
  • ghs pour les jetons serveur à utilisateur GitHub
  • gho pour les jetons d’accès OAuth
  • ghr pour les jetons d’actualisation

De plus, ces préfixes comportent un séparateur (_) dans le jeton afin d’en améliorer la lisibilité. Un trait de soulignement n’est pas un caractère Base64, ce qui permet de s’assurer que les chaînes générées de manière aléatoire comme les algorithmes de hachage sécurisé (SHA) ne peuvent pas dupliquer accidentellement ces jetons. Les préfixes permettent aussi de réduire le taux de faux positifs dans le cadre d’une analyse des secrets, ce qui constitue une fonctionnalité de sécurité avancée de GitHub pour renforcer la sécurité au sein de votre dépôt GitHub.

Limites de débit des jetons

Le dépassement des limites de débit peut entraîner une perte de temps de développement. Intéressons-nous aux limites de débit des applications GitHub et des applications OAuth. Si vous comprenez bien les limites de débit, vous pouvez être une ressource pour les développeurs de votre équipe, en les aidant à optimiser l’investissement de votre organisation dans ces ressources GitHub.

Les limites de débit permettent de contrôler le débit du trafic sur GitHub et se basent sur le nombre de demandes par heure.

  • Une application GitHub installée sur un compte d’entreprise GitHub est soumise à une limite de débit de demandes de 15 000 demandes par heure.
  • Une application OAuth est authentifiée auprès d’un utilisateur individuel et limitée à 5 000 demandes par heure.

Pour les administrateurs d’enterprise, vous devez superviser les limites de débit d’application et collaborer avec les développeurs pour ajuster leurs scripts afin qu’ils restent dans ces limites. En règle générale, les limites de débit ne constituent pas un problème tant que votre développeur n’écrit pas un script qui demande un trop grand nombre d’informations dans un workflow. Le développement s’arrête soudain et les limites de débit deviennent un goulet d’étranglement. Vous pouvez éviter ces problèmes de dépassement des limites de débit en limitant le nombre de demandes par heure ou en modifiant un workflow de façon à imposer un temps d’attente entre les demandes. Si vous dépassez votre limite de débit à l’aide de l’authentification de base ou d’OAuth, vous pouvez probablement résoudre le problème en mettant en cache les réponses d’API et en utilisant des demandes conditionnelles.

À partir de la console de gestion, vous pouvez configurer une limite de débit personnalisée pour les utilisateurs non authentifiés dans votre entreprise et créer une liste d’exemptions autorisant certains utilisateurs à utiliser la limite de débit d’API totale.

Capture d’écran de la console de gestion définissant les limites de débit d’API.

Vous pouvez vérifier à tout moment l’état actuel de la limite de débit en utilisant l’API de limite de débit suivante. Les en-têtes HTTP retournés de toute demande d’API indiquent l’état actuel des limites de débit.

curl \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/rate_limit

Exemple de réponse

{
  "resources": {
    "core": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1372700873,
      "used": 1
    },
    "search": {
      "limit": 30,
      "remaining": 18,
      "reset": 1372697452,
      "used": 12
    },
    "graphql": {
      "limit": 5000,
      "remaining": 4993,
      "reset": 1372700389,
      "used": 7
    },
    "integration_manifest": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1551806725,
      "used": 1
    },
    "code_scanning_upload": {
      "limit": 500,
      "remaining": 499,
      "reset": 1551806725,
      "used": 1
    }
  },
  "rate": {
    "limit": 5000,
    "remaining": 4999,
    "reset": 1372700873,
    "used": 1
  }
}

Pour plus d’informations sur les limites de débit, référencez la limitation du taux sur GitHub Docs.