Identificer understøttede adgangstokens

  • 8 minutter

Her lærer du om de forskellige GitHub-adgangstokens, deres applikationer, begrænsninger og hastighedsgrænser.

Når du giver adgang til brugere i din virksomhed, er godkendelse utrolig vigtig. Brugeradgangen skal være tæt begrænset og kun inkludere det, der er nødvendigt for brugerne at udføre deres opgaver. Det er vigtigt at forstå de forskellige adgangstokens, da du hjælper brugerne i virksomheden med at bruge den bedste løsning til deres use cases.

GitHub bruger forskellige tokens, der giver brugerne mulighed for at godkende de forskellige aktiviteter, de skal udføre. Normalt er disse forskellige tokens ligetil, og det er nemt at vide, hvilket token der skal bruges. Men nogle gange kan flere tokens bruges til at opnå det samme resultat, så valg af et token kan komme ned til en beslutning om god, bedre og bedst. I disse situationer er det vigtigt at identificere egenskaberne for GitHubs tokens, og hvordan du kan omfang et tokens adgang korrekt. Her er en liste over de forskellige tilgængelige adgangstokens:

  • Personlige GitHub-adgangstokens
  • GitHub-tokens fra bruger til server
  • GitHub-server-til-server-tokens
  • OAuth-adgangstokens
  • Opdater tokens

Det er vigtigt at tilskynde dit udviklingsteam til at bruge tokens med det rette omfang, så risikoen hurtigt kan afhjælpes, når en sikkerhedsrisiko opdages. Lad os se nærmere på hver af disse adgangstokens.

Personlige adgangstokens

Et personligt adgangstoken (PAT) er et alternativ til at bruge en adgangskode til godkendelse til GitHub. GitHub skal bekræfte brugeradgangen for at kunne pushe og hente lagre. Bekræftelsen udføres via en brugers bekræftede mailadresse. Du kan oprette lige så mange personlige adgangstokens, som din arbejdsproces kræver, og du skal behandle dem lige så sikkert som adgangskoder. Brug af forskellige tokens til forskellige programmer er den bedste praksis for sikkerhed. Hvis du vil oprette et personligt adgangstoken i GitHub, skal du gå til Indstillinger og under Udviklerindstillinger vælge Personlige adgangstokens.

Skærmbillede med et eksempel på et personligt GitHub-adgangstoken.

Du kan begrænse et individuelt token til kun at tillade den adgang, der kræves for at godkende det job, du tildeler det til. Tokenet er knyttet til en bestemt bruger og er i overensstemmelse med brugerens adgang til organisationen og lagrene. Du kan til enhver tid tilbagekalde et personligt adgangstoken, hvilket er særligt vigtigt, når der opstår et sikkerhedsproblem. Det er vigtigt at kommunikere til dit team, at deres personlige adgangstokens skal behandles lige så sikkert som et brugernavn og en adgangskode. Hvis et token bliver kompromitteret, skal du øjeblikkeligt gøre noget for at tilbagekalde tokenet.

Du kan finde detaljerede trin til oprettelse af et personligt adgangstoken her: Oprettelse af et personligt adgangstoken – GitHub Docs

Enhedstokens

Et enhedstoken er dybest set en maskinkontoversion af en PAT, der bruges i forbindelse med en enhed, som giver adgang til et specifikt lager i specifikke brugstilfælde, der ikke er bundet til brugeren. En programkonfiguration ved hjælp af et OAuth-flow bruger et enhedstoken. De bruges typisk sammen med løbere, særlige applikationstjenester, Cron-job (i Linux) eller andre lignende scenarier relateret til automatiserede opgaver. Ligesom det personlige adgangstoken er enhedstokenet knyttet til en individuel konto, og den konto, som du opretter enhedstokenet for, bruger en licens.

Tokens til installation af GitHub-program

Et installationstoken gør det muligt for en GitHub-app at foretage godkendte API-anmodninger for programmets installation i en organisation. Før du opretter et installationstoken, skal du først installere den GitHub-app, som tokenet gælder for, i destinationslageret. Installationstokens er gyldige i en time og er sikre, fordi de genereres til et bestemt formål og udløber på relativt kort tid.

OAuth-adgangstokens

OAuth2-tokens bruges til at godkende brugere til OAuth-standardapps, der kører i browseren, og til hovedløse apps, f.eks. CLI-værktøjer. De giver din app adgang til API'en med et brugeradgangstoken. Med disse tokens kan du oprette forbindelse mellem din GitHub-brugeridentitet og tredjepartsprogrammer, så appen kan udføre handlinger på dine vegne. Hvis du f.eks. vil bruge en app, der anmoder om user:email omfang, får appen skrivebeskyttet adgang til dine private mailadresser. Disse tokens kan erhverves ved hjælp af webprogramflow til produktionsprogrammer. Fordi disse tokens er kortsigtede og udløber om 10 minutter, er de også sikre.

Opdater tokens

Et opdateringstoken er forbundet med et OAuth-token. Når der tildeles et nyt OAuth-token (via en bruger-til-server-anmodning), inkluderes der et opdateringstoken i svaret. Når brugertokenet udløber, kan opdateringstokenet udveksles til et nyt brugertoken med en anmodning om tilbagekald. Hver gang der udstedes et nyt OAuth-token, inkluderes der et opdateringstoken. Opdateringstokens er gyldige i seks måneder og er en god påmindelse om at opdatere dine OAuth-tokens.

Identificerbare præfikser

Som vi kan se på tværs af branchen, er tokenpræfikser en klar måde at gøre tokens identificerbare på. GitHub indeholder præfikser på tre bogstaver til at repræsentere hvert token. Præfikset starter med to bogstaver, der angiver virksomheden, ghog efterfølges af det første bogstav i tokentypen. Præfikserne for de tilgængelige adgangstokentyper er:

  • ghp til personlige GitHub-adgangstokens
  • ghu til GitHub-bruger-til-server-tokens
  • ghs til GitHub-server-til-server-tokens
  • gho til OAuth-adgangstokens
  • ghr til opdateringstokens

Desuden har disse præfikser en separator (_) i tokenet for at forbedre læsbarheden. Et understregningstegn er ikke et Base64-tegn, hvilket er med til at sikre, at tilfældigt genererede strenge som Secure Hash Algorithms (SHA'er) ikke ved et uheld kan duplikere disse tokens. Præfikser hjælper også med at reducere den falske positive rate for hemmelig scanning, som er en avanceret GitHub-sikkerhedsfunktion til yderligere at forbedre sikkerheden i dit GitHub-lager.

Grænser for tokenhastigheder

Overskridelse af hastighedsgrænser kan føre til mistet udviklingstid. Lad os tale om hastighedsgrænser for GitHub-apps og OAuth-apps. Ved at forstå hastighedsgrænser kan du være en ressource for udviklere i dit team og hjælpe med at optimere din organisations investering i disse GitHub-ressourcer.

Hastighedsgrænser hjælper med at styre trafikhastigheden på GitHub og er baseret på anmodninger pr. time.

  • En GitHub-app, der er installeret på en GitHub-virksomhedskonto, har grænsen for anmodningsfrekvensen ved 15.000 anmodninger pr. time.
  • En OAuth-app godkendes af en individuel bruger og er begrænset til 5.000 anmodninger pr. time.

For virksomhedsadministratorer skal du overvåge grænser for apphastigheder og samarbejde med udviklerne om at justere deres scripts for at holde sig inden for grænserne. Normalt er hastighedsgrænserne ikke et problem, før din udvikler gør noget som at skrive et script, der anmoder om for mange oplysninger i en arbejdsproces. Pludselig går udviklingen i stå, og hastighedsgrænserne bliver en flaskehals. Du kan undgå disse problemer med overskridelse af hastighedsgrænser ved at begrænse antallet af anmodninger pr. time eller ændre en arbejdsproces for at vente mellem anmodninger. Hvis du overskrider din satsgrænse ved hjælp af basisgodkendelse eller OAuth, kan du sandsynligvis løse problemet ved at cachelagring af API-svar og ved hjælp af betingede anmodninger.

Fra administrationskonsollen kan du konfigurere en brugerdefineret satsgrænse for ikke-godkendte brugere i din virksomhed og oprette en liste over undtagelser, så visse brugere kan bruge den fulde API-satsgrænse.

Skærmbillede af administrationskonsollen, der angiver API-hastighedsgrænserne.

Du kan til enhver tid kontrollere din aktuelle status for rate-limit ved hjælp af følgende API til hastighedsgrænse. De returnerede HTTP-headere for en hvilken som helst API-anmodning viser din aktuelle status for satsgrænse.

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

Eksempel på svar

{
  "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
  }
}

Du kan finde flere oplysninger om hastighedsgrænser i Hyppighedsbegrænsning på GitHub Docs.