Identifier les jetons d’accès pris en charge

  • 8 minutes

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

Dès lors qu’il s’agit d’accorder l’accès à un utilisateur au sein de votre entreprise, l’authentification s’avère 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 en matière de sécurité. Pour créer un jeton d’accès personnel dans GitHub, accédez à Paramètres, puis sous Paramètres de développeur, vous trouverez Jetons d’accès personnels.

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

Vous pouvez définir l’étendue d’un jeton individuel au seul accès nécessaire pour authentifier le travail pour lequel il va être attribué. 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 s’avère particulièrement important en cas d’attaque de sécurité. 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.

Les é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 correspond grosso modo à la version compte d’ordinateur d’un PAT. Il est utilisé dans le contexte d’un appareil et donne accès à un dépôt spécifique dans des cas d’usage spécifiques non liés à un utilisateur. La configuration d’une application à l’aide d’un flux OAuth utilise un jeton d’appareil. Ce dernier est généralement utilisé avec des exécuteurs, des services d’application spéciaux, des travaux Cron (dans Linux) ou d’autres scénarios similaires liés à des tâches automatisées. À l’instar du jeton d’accès personnel, il 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, l’application GitHub à laquelle le jeton sera appliqué a besoin d’être installée dans le dépôt de destination. Les jetons d’installation sont valides pendant 1 heure et, comme ils sont générés dans un but précis et qu’ils expirent à l’issue d’un laps de temps relativement bref, ils sont sécurisés.

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 voulez utiliser une application qui demande l’étendue user:email, cette application aura accès en lecture seule à vos adresses e-mail privées. Ces jetons peuvent être obtenus à l’aide du flux d’application web des applications de production. Étant donné que ces jetons sont à court terme et qu’ils expirent au bout de 10 minutes, ils sont aussi 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. Ces préfixes commencent par les deux lettres gh, suivies de la lettre correspondant au type de jeton. Ces types de jetons 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 fait que ces jetons ne peuvent pas être dupliqués accidentellement par des chaînes générées de façon aléatoire comme des SHA. Ces 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 en utilisant une authentification de base ou OAuth, vous avez de grandes chances de résoudre le problème en mettant en cache les réponses de l’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 de l’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, consultez Limites de débit sur GitHub Docs.