Ondersteunde toegangstokens identificeren

  • 8 minuten

Hier leert u meer over de verschillende GitHub-toegangstokens, hun toepassingen, beperkingen en frequentielimieten.

Wanneer u toegang verleent aan gebruikers binnen uw bedrijf, is verificatie ongelooflijk belangrijk. Gebruikerstoegang moet strikt worden beperkt en alleen bevatten wat nodig is voor gebruikers om hun taken te voltooien. Het is belangrijk om inzicht te krijgen in de verschillende toegangstokens, omdat u gebruikers binnen het bedrijf helpt de beste optie te gebruiken voor hun gebruiksvoorbeelden.

GitHub gebruikt verschillende tokens waarmee gebruikers zich kunnen verifiëren bij de verschillende activiteiten die ze moeten uitvoeren. Deze verschillende tokens zijn meestal eenvoudig en het is eenvoudig om te weten welk token moet worden gebruikt. Maar soms kunnen meerdere tokens worden gebruikt om hetzelfde resultaat te bereiken, dus het kiezen van een token kan leiden tot een beslissing van goed, beter en het beste. In deze situaties is het belangrijk om de kenmerken van de tokens van GitHub te identificeren en de toegang van een token correct te bepalen. Hier volgt een lijst met de verschillende toegangstokens die beschikbaar zijn:

  • Persoonlijke gitHub-toegangstokens
  • GitHub-tokens voor gebruikers naar server
  • GitHub server-naar-servertokens
  • OAuth-toegangstokens
  • Tokens vernieuwen

Het is belangrijk om uw ontwikkelteam aan te moedigen tokens te gebruiken met het juiste bereik, zodat het risico snel kan worden beperkt wanneer een beveiligingsprobleem wordt gedetecteerd. Laten we eens kijken naar elk van deze toegangstokens.

Persoonlijk toegangstokens

Een persoonlijk toegangstoken (PAT) is een alternatief voor het gebruik van een wachtwoord voor verificatie bij GitHub. Om opslagplaatsen te pushen en op te halen, moet GitHub de gebruikerstoegang verifiëren. De verificatie wordt uitgevoerd via het geverifieerde e-mailadres van een gebruiker. U kunt zoveel persoonlijke toegangstokens maken als uw werkstroom nodig heeft en u moet ze veilig behandelen als wachtwoorden. Het gebruik van verschillende tokens voor verschillende toepassingen is de aanbevolen procedure voor beveiliging. Als u een persoonlijk toegangstoken wilt maken in GitHub, gaat u naar Instellingen en selecteert u persoonlijke toegangstokens onder Instellingen voor ontwikkelaars.

Schermopname met een voorbeeld van een persoonlijk GitHub-toegangstoken.

U kunt een afzonderlijk token instellen om alleen de toegang toe te staan die is vereist voor het verifiëren van de taak waaraan u deze toewijst. Het token is gekoppeld aan een specifieke gebruiker en is afgestemd op de toegang van de gebruiker tot de organisatie en opslagplaatsen. U kunt een persoonlijk toegangstoken op elk gewenst moment intrekken, wat met name belangrijk is wanneer er een beveiligingsprobleem optreedt. Het is belangrijk om met uw team te communiceren dat hun persoonlijke toegangstokens veilig moeten worden behandeld als een gebruikersnaam en wachtwoord. Als een token in gevaar komt, moet u onmiddellijk actie ondernemen om het token in te trekken.

Gedetailleerde stappen voor het maken van een persoonlijk toegangstoken zijn hier beschikbaar: Een persoonlijk toegangstoken maken - GitHub Docs

Apparaattokens

Een apparaattoken is in feite een computeraccountversie van een PAT, die wordt gebruikt in de context van een apparaat, die toegang geeft tot een specifieke opslagplaats in specifieke gebruiksvoorbeelden die niet-gebruikersgebonden zijn. Voor het instellen van een toepassing met behulp van een OAuth-stroom wordt een apparaattoken gebruikt. Ze worden meestal gebruikt met hardlopers, speciale toepassingsservices, Cron-taken (in Linux) of andere vergelijkbare scenario's met betrekking tot geautomatiseerde taken. Net als het persoonlijke toegangstoken is het apparaattoken gekoppeld aan een afzonderlijk account en het account waarvoor u het apparaattoken maakt, verbruikt een licentie.

Installatietokens voor GitHub-toepassingen

Met een installatietoken kan een GitHub-app geverifieerde API-aanvragen indienen voor de installatie van de toepassing in een organisatie. Voordat u een installatietoken maakt, moet u eerst de GitHub-app installeren waarop het token van toepassing is, in de doelopslagplaats. Installatietokens zijn één uur geldig en zijn veilig omdat ze worden gegenereerd voor een specifiek doel en in relatief korte tijd verlopen.

OAuth-toegangstokens

OAuth2-tokens worden gebruikt om gebruikers te autoriseren voor standaard-OAuth-apps die worden uitgevoerd in de browser en voor headless apps zoals CLI-hulpprogramma's. Ze bieden uw app toegang tot de API met een token voor gebruikerstoegang. Met deze tokens kunt u uw GitHub-gebruikersidentiteit verbinden met toepassingen van derden, zodat de app namens u acties kan uitvoeren. Als u bijvoorbeeld een app wilt gebruiken die een bereik aanvraagt user:email , krijgt de app alleen-lezentoegang tot uw privé-e-mailadressen. Deze tokens kunnen worden verkregen met behulp van de webtoepassingsstroom voor productietoepassingen. Omdat deze tokens op korte termijn zijn en binnen 10 minuten verlopen, zijn ze ook veilig.

Tokens vernieuwen

Een refresh-token is verbonden met een OAuth-token. Wanneer een nieuw OAuth-token (via een gebruikers-naar-server-aanvraag) wordt verleend, wordt er een vernieuwingstoken opgenomen in het antwoord. Wanneer het gebruikerstoken verloopt, kan het verversingstoken worden uitgewisseld voor een nieuw gebruikerstoken met een callback-aanvraag. Telkens wanneer een nieuw OAuth-token wordt uitgegeven, wordt er een vernieuwingstoken opgenomen. Vernieuwingstokens zijn zes maanden geldig en zijn een goede herinnering om uw OAuth-tokens bij te werken.

Identificeerbare voorvoegsels

Zoals we in de hele branche zien, zijn tokenvoorvoegsels een duidelijke manier om tokens identificeerbaar te maken. GitHub bevat drieletterige voorvoegsels die elk token vertegenwoordigen. Het voorvoegsel begint met twee letters die het bedrijf ghondertekenen en wordt gevolgd door de eerste letter van het tokentype. De voorvoegsels voor de beschikbare toegangstokentypen zijn:

  • ghp voor persoonlijke gitHub-toegangstokens
  • ghu voor GitHub-gebruiker-naar-server tokens
  • ghs voor GitHub-server-naar-server-tokens
  • gho voor OAuth-toegangstokens
  • ghr voor vernieuwingstokens

Daarnaast hebben deze voorvoegsels een scheidingsteken (_) binnen het token om de leesbaarheid te verbeteren. Een onderstrepingsteken is geen Base64-teken, wat ervoor zorgt dat willekeurig gegenereerde tekenreeksen zoals Secure Hash Algorithms (SHA's) deze tokens niet per ongeluk kunnen dupliceren. Voorvoegsels helpen ook het aantal fout-positieven voor het scannen van geheimen te verminderen. Dit is een geavanceerde Beveiligingsfunctie van GitHub om de beveiliging in uw GitHub-opslagplaats verder te verbeteren.

Tokenlimieten voor snelheid

Het overschrijden van frequentielimieten kan leiden tot verloren ontwikkelingstijd. Laten we het hebben over frequentielimieten voor GitHub-apps en OAuth-apps. Door inzicht te krijgen in frequentielimieten, kunt u een resource zijn voor ontwikkelaars in uw team, zodat u de investering van uw organisatie in deze GitHub-resources kunt optimaliseren.

Frequentielimieten helpen bij het beheren van de snelheid van verkeer op GitHub en zijn gebaseerd op aanvragen per uur.

  • Een GitHub-app die is geïnstalleerd op een GitHub Enterprise-account, heeft de aanvraagsnelheidslimiet voor 15.000 aanvragen per uur.
  • Een OAuth-app wordt geverifieerd voor een afzonderlijke gebruiker en is beperkt tot 5000 aanvragen per uur.

Voor Enterprise-beheerders moet u de frequentielimieten van apps bewaken en samenwerken met de ontwikkelaars om hun scripts aan te passen om binnen de limieten te blijven. De frequentielimieten zijn meestal geen probleem totdat uw ontwikkelaar iets doet, zoals het schrijven van een script dat te veel informatie in een workflow aanvraagt. Plotseling komt ontwikkeling tot stilstand en snelheidslimieten worden een knelpunt. U kunt deze snelheidslimietoverschrijdingsproblemen voorkomen door het aantal aanvragen per uur te beperken of door een werkstroom te wijzigen om te wachten tussen aanvragen. Als u de frequentielimiet overschrijdt met behulp van basisverificatie of OAuth, kunt u het probleem waarschijnlijk oplossen door API-antwoorden in de cache op te slaan en voorwaardelijke aanvragen te gebruiken.

Vanuit de beheerconsole kunt u een aangepaste frequentielimiet instellen voor niet-geverifieerde gebruikers in uw onderneming en een uitzonderingslijst maken, zodat bepaalde gebruikers de volledige API-frequentielimiet kunnen gebruiken.

Schermopname van het instellen van de API-frequentielimieten in de beheerconsole.

U kunt de huidige status van de frequentielimiet op elk gewenst moment controleren met behulp van de volgende Frequentielimiet-API. In de geretourneerde HTTP-headers van een API-aanvraag wordt de huidige frequentielimietstatus weergegeven.

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

Voorbeeld van een antwoord

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

Voor meer gedetailleerde informatie over frequentielimieten, raadpleeg Rate limiting op GitHub Docs.