Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-09-25. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Generieren eines Benutzerzugriffstokens für eine GitHub-App

Du kannst ein Benutzerzugriffstoken für deine GitHub App generieren, um die App-Aktivität einzelnen Benutzer*innen zuzuordnen.

Informationen zu Benutzerzugriffstoken

Note

Ablaufende Benutzerzugriffstoken sind derzeit ein optionales Feature, das noch geändert werden kann. Informationen zum Aktivieren oder Deaktivieren des Tokenablauffeatures findest du unter Aktivieren optionaler Features für GitHub-Apps. Weitere Informationen findest du unter Ablauf von Benutzer-zu-Server-Zugriffstoken für GitHub Apps.

Wenn eine Benutzerin meldet, dass nach der Autorisierung deiner GitHub App keine Ressourcen im Besitz seiner bzw. ihrer Organisation angezeigt werden können und die Organisation SAML-SSO verwendet, weise dendie Benutzerin an, vor der erneuten Autorisierung eine aktive SAML-Sitzung für die Organisation zu starten. Weitere Informationen findest du in der Dokumentation zu GitHub Enterprise Cloud unter SAML- und GitHub-Apps.

Ein Benutzerzugriffstoken ist ein OAuth-Tokentyp. Im Gegensatz zu herkömmlichen OAuth-Token verwendet das Benutzerzugriffstoken keine Bereiche. Stattdessen werden differenzierte Berechtigungen verwendet. Ein Benutzerzugriffstoken verfügt nur über Berechtigungen, die sowohl die Benutzerinnen als auch die App besitzen. Wenn der App beispielsweise die Berechtigung zum Schreiben des Inhalts eines Repositorys erteilt wurde, die Benutzerinnen jedoch nur den Inhalt lesen können, erhält das Benutzerzugriffstoken nur die Berechtigung zum Lesen des Inhalts.

Ebenso kann ein Benutzerzugriffstoken nur auf Ressourcen zugreifen, auf die sowohl die Benutzerinnen als auch die App zugreifen können. Wenn beispielsweise einer App Zugriff auf die Repositorys A und B gewährt wurde und die Benutzerinnen Zugriff auf die Repositorys B und C haben, kann das Benutzerzugriffstoken auf das Repository B zugreifen, aber nicht auf A oder C. Du kannst mithilfe der REST-API überprüfen, auf welche Installationen und welche Repositorys innerhalb einer Installation ein Benutzerzugriffstoken zugreifen kann. Weitere Informationen findest du unter GET /user/installations und GET /user/installations/{installation_id}/repositories unter Rest-API-Endpunkte für GitHub App-Installationen.

Wenn du API-Anforderungen mit einem Benutzerzugriffstoken stellen, gelten die Ratenlimits für Benutzerzugriffstoken. Weitere Informationen findest du unter Rate limits for GitHub Apps (Ratenbegrenzungen für GitHub-Apps).

Standardmäßig läuft ein Benutzerzugriffstoken nach 8 Stunden ab. Du kannst ein Aktualisierungstoken verwenden, um ein Benutzerzugriffstoken erneut zu generieren. Weitere Informationen findest du unter Aktualisieren von Benutzerzugriffstoken.

Benutzerinnen können die Autorisierung einer GitHub App widerrufen. Weitere Informationen findest du unter Tokenablauf und Sperrung. Wenn Benutzerinnen die Autorisierung einer GitHub App widerrufen, erhält die App den Webhook github_app_authorization. GitHub Apps können dieses Ereignis nicht abbestellen. Wenn deine App diesen Webhook empfängt, solltest du den Aufruf der API im Namen der Benutzer*innen beenden, die das Token widerrufen haben. Wenn deine App ein widerrufenes Zugriffstoken weiterhin verwendet, erhält sie den Fehler 401 Bad Credentials. Weitere Informationen zu diesem Webhook findest du unter Webhook-Ereignisse und -Nutzlasten.

Du musst Benutzerzugriffstoken und Aktualisierungstoken sicher aufbewahren. Weitere Informationen findest du unter Best Practices beim Erstellen einer GitHub-App.

Verwenden des Webanwendungsflusses zum Generieren eines Benutzerzugriffstokens

Wenn deine App im Browser ausgeführt wird, solltest du den Webanwendungsfluss verwenden, um ein Benutzerzugriffstoken zu generieren. Ein Tutorial zur Verwendung des Webanwendungsflusses findest du unter Erstellen der Schaltfläche „Mit GitHub anmelden“ mit einer GitHub-App.

  1. Leite die Benutzer*innen an diese URL weiter, und füge alle erforderlichen Abfrageparameter aus der folgenden Liste von Parametern hinzu: http(s)://HOSTNAME/login/oauth/authorize. Diese URL gibt beispielsweise die Parameter client_id und state an: http(s)://HOSTNAME/login/oauth/authorize?client_id=12345&state=abcdefg.

    Query parameter (Abfrageparameter)typeErforderlich?Beschreibung
    client_idstringErforderlichDie Client-ID für deine GitHub App. Die Client-ID unterscheidet sich von der App-ID. Du findest die Client-ID auf der Einstellungsseite deiner App. Weitere Informationen zum Aufrufen der Einstellungsseite für deine GitHub App findest du unter Ändern einer GitHub-App-Registrierung.
    redirect_uristringDringend empfohlenDie URL in der Anwendung, an die Benutzer nach der Autorisierung gesendet werden. Sie muss genau mit einer der URLs übereinstimmen, die du als „Rückruf-URL“ in den Einstellungen deiner App angegeben hast, und sie darf keine zusätzlichen Parameter enthalten.
    statestringDringend empfohlenBei der Angabe sollte zum Schutz vor Fälschungsangriffen eine zufällige Zeichenfolge eingefügt werden. Sie kann auch andere beliebige Daten enthalten.
    loginstringOptionalWenn eine Angabe erfolgt, übergibt der Webanwendungsfluss Benutzer*innen ein bestimmtes Konto, das sie für die Anmeldung und Autorisierung deiner App verwenden können.
    allow_signupbooleanOptionalGibt an, ob nicht authentifizierten Benutzer*innen während des OAuth-Flusses eine Option zum Registrieren bei GitHub angeboten wird. Der Standardwert lautet true. Verwende false, wenn eine Richtlinie die Anmeldung verbietet.
  2. Wenn die Benutzer*innen deine Autorisierungsanforderung akzeptieren, leitet GitHub sie zu einer der Rückruf-URLs in deinen App-Einstellungen um und stellt einen code-Abfrageparameter bereit, mit dem du im nächsten Schritt ein Benutzerzugriffstoken erstellen kannst. Wenn du im vorherigen Schritt redirect_uri angegeben hast, wird diese Rückruf-URL verwendet. Andernfalls wird die erste Rückruf-URL auf der Einstellungsseite deiner App verwendet.

    Wenn du im vorherigen Schritt den state-Parameter angegeben hast, enthält GitHub auch einen state-Parameter. Wenn der state-Parameter nicht mit dem state-Parameter übereinstimmt, den du im vorherigen Schritt übermittelt hast, kann die Anforderung nicht als vertrauenswürdig gelten, und der Webanwendungsfluss sollte abgebrochen werden.

  3. Tausche das code-Element aus dem vorherigen Schritt gegen ein Benutzerzugriffstoken aus, indem du eine POST-Anforderung an diese URL sendest und dabei folgende Abfrageparameter angibst: http(s)://HOSTNAME/login/oauth/access_token

    Query parameter (Abfrageparameter)typeBESCHREIBUNG
    client_idstringErforderlich. Die Client-ID für deine GitHub App. Die Client-ID unterscheidet sich von der App-ID. Du findest die Client-ID auf der Einstellungsseite deiner App. Weitere Informationen zum Aufrufen der Einstellungsseite für deine GitHub App findest du unter Ändern einer GitHub-App-Registrierung.
    client_secretstringErforderlich. Der geheime Clientschlüssel für deine GitHub App. Du kannst einen geheimen Clientschlüssel auf der Einstellungsseite für deine App generieren.
    codestringErforderlich. Der Code, den du im vorherigen Schritt erhalten hast.
    redirect_uristringDie URL in der Anwendung, an die Benutzer nach der Autorisierung gesendet werden. Diese muss genau mit einer der URLs übereinstimmen, die du beim Einrichten deiner GitHub App als „Rückruf-URL“ angegeben hast. Sie darf keine zusätzlichen Parameter enthalten.
    repository_idstringDie ID eines einzelnen Repositorys, auf das das Benutzerzugriffstoken zugreifen kann. Wenn die GitHub App oder dieder Benutzerin nicht auf das Repository zugreifen kann, wird dies ignoriert. Verwende diesen Parameter, um den Zugriff auf das Benutzerzugriffstoken weiter einzuschränken.
  4. GitHub gibt eine Antwort, die folgende Parameter enthält:

    AntwortparametertypeBeschreibung
    access_tokenstringDas Benutzerzugriffstoken. Das Token beginnt mit ghu_.
    expires_inintegerDie Anzahl der Sekunden bis zum Ablauf des access_token. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Der Wert ist immer 28800 (8 Stunden).
    refresh_tokenstringDas Aktualisierungstoken. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Das Token beginnt mit ghr_.
    refresh_token_expires_inintegerDie Anzahl der Sekunden bis zum Ablauf des refresh_token. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Der Wert ist immer 15897600 (6 Monate).
    scopestringDie Bereiche für das Token. Dieser Wert ist immer eine leere Zeichenfolge. Im Gegensatz zu einem herkömmlichen OAuth-Token ist das Benutzerzugriffstoken auf die Berechtigungen beschränkt, die sowohl deiner App als auch den Benutzer*innen zugewiesen wurden.
    token_typestringDer Tokentyp. Der Wert ist immer bearer.
  5. Verwende das Benutzerzugriffstoken aus dem vorherigen Schritt, um API-Anforderungen im Namen von Benutzer*innen auszuführen. Schließe das Benutzerzugriffstoken in den Authorization-Header einer API-Anforderung ein. Zum Beispiel:

    curl --request GET \
    --url "http(s)://HOSTNAME/api/v3/user" \
    --header "Accept: application/vnd.github+json" \
    --header "Authorization: Bearer USER_ACCESS_TOKEN" \
    --header "X-GitHub-Api-Version: 2022-11-28"
    

Verwenden des Geräteflusses zum Generieren eines Benutzerzugriffstokens

Note

Der Gerätefluss befindet sich in beta und kann geändert werden.

Wenn deine App monitorlos ist oder keinen Zugriff auf einen Browser hat, solltest du den Gerätefluss verwenden, um ein Benutzerzugriffstoken zu generieren. Beispielsweise sollten CLI-Tools, einfache Raspberry Pi-Geräte und Desktopanwendungen den Gerätefluss verwenden. Ein Tutorial zur Verwendung des Geräteflusses findest du unter Erstellen einer CLI mit einer GitHub-App.

Bevor Sie den Gerätefluss verwenden können, müssen Sie ihn zuerst in den Einstellungen Ihrer App aktivieren. Weitere Informationen zum Aktivieren des Geräteflusses findest du unter Ändern einer GitHub-App-Registrierung.

Im Gerätefluss wird die Erweiterung OAuth 2.0 Device Authorization Grant verwendet.

  1. Sende eine POST-Anforderung zusammen mit einem client_id-Abfrageparameter an http(s)://HOSTNAME/login/device/code. Die Client-ID unterscheidet sich von der App-ID. Du findest die Client-ID auf der Einstellungsseite deiner App. Weitere Informationen zum Aufrufen der Einstellungsseite für deine GitHub App findest du unter Ändern einer GitHub-App-Registrierung.

  2. GitHub gibt eine Antwort, die die folgenden Abfrageparameter enthält:

    AntwortparametertypeBeschreibung
    device_codestringEin Prüfcode zum Überprüfen des Geräts. Dieser Code ist 40 Zeichen lang.
    user_codestringEin Prüfcode, den deine Anwendung anzeigen sollte, damit die Benutzer*innen ihn in einem Browser eingeben können. Dieser Code umfasst 8 Zeichen mit einem Bindestrich in der Mitte. Beispiel: WDJB-MJHT.
    verification_uristringDie URL, unter die Benutzer*innen ihren user_code eingeben müssen. Die URL lautet: http(s)://HOSTNAME/login/device.
    expires_inintegerDie Anzahl der Sekunden, bevor device_code und user_code ablaufen. Der Standardwert beträgt 900 Sekunden (15 Minuten).
    intervalintegerDie Zeit in Sekunden, die mindestens verstreichen muss, bevor du eine neue Zugriffstokenanforderung (POST http(s)://HOSTNAME/login/oauth/access_token) vornehmen kannst, um die Geräteautorisierung abzuschließen. Wenn du vor Ablauf dieses Zeitraums eine Anforderung übermittelst, wird der Grenzwert für die Rate erreicht und ein slow_down-Fehler angezeigt. Die Standardeinstellung ist 5 Sekunden.
  3. Fordere die Benutzer*innen auf, den user_code aus dem vorherigen Schritt unter http(s)://HOSTNAME/login/device einzugeben.

    Wenn die Benutzer*innen den Code nicht vor Ablauf des expires_in-Zeitraums eingeben, wird der Code ungültig. In diesem Fall solltest du den Gerätefluss neu starten.

  4. Rufe POST http(s)://HOSTNAME/login/oauth/access_token zusammen mit den Abfrageparametern client_id, device_code und grant_type (unten beschrieben) ab, bis die Geräte- und Benutzercodes ablaufen oder die Benutzer*innen die App durch Eingabe des user_code erfolgreich autorisiert haben.

    Query parameter (Abfrageparameter)typeBESCHREIBUNG
    client_idstringErforderlich. Die Client-ID für deine GitHub App
    device_codestringErforderlich. Der Geräteprüfcode, den du im vorherigen Schritt erhalten hast.
    grant_typestringErforderlich. Der Gewährungstyp muss urn:ietf:params:oauth:grant-type:device_code sein.
    repository_idstringDie ID eines einzelnen Repositorys, auf das das Benutzerzugriffstoken zugreifen kann. Wenn die GitHub App oder dieder Benutzerin nicht auf das Repository zugreifen kann, wird dies ignoriert. Verwende diesen Parameter, um den Zugriff auf das Benutzerzugriffstoken weiter einzuschränken.

    Rufe diesen Endpunkt nicht in kürzeren Abständen als durch interval angegeben ab. Andernfalls wird der Grenzwert für die Rate erreicht und ein slow_down-Fehler angezeigt. Die slow_down-Fehlerantwort fügt dem letzten Intervall (interval) 5 Sekunden hinzu.

    Bis Benutzer*innen den Code eingeben, antwortet GitHub mit dem Status „200“ und dem Antwortabfrageparameter error.

    FehlerbezeichnungBESCHREIBUNG
    authorization_pendingDieser Fehler tritt auf, wenn die Autorisierungsanforderung aussteht und der Benutzer noch nicht den Benutzercode eingegeben hat. Von der App wird erwartet, dass sie POST http(s)://HOSTNAME/login/oauth/access_token weiterhin mit einer Häufigkeit abfragt, die nicht schneller als die durch interval angegebene Häufigkeit ist.
    slow_downWenn du den slow_down-Fehler erhältst, werden 5 zusätzliche Sekunden dem Mindestintervall (interval) oder -zeitrahmen hinzugefügt, das bzw. der zwischen deinen Anforderungen mit POST http(s)://HOSTNAME/login/oauth/access_token erforderlich ist. Wenn beispielsweise für das Startintervall mindestens 5 Sekunden zwischen Anforderungen erforderlich waren und ein slow_down-Fehler angezeigt wird, musst du jetzt mindestens 10 Sekunden warten, bevor du eine neue Anforderung für ein Token vornimmst. Die Fehlerantwort enthält den neuen Wert für interval, den du verwenden musst.
    expired_tokenWenn der Gerätecode abgelaufen ist, wird der token_expired-Fehler angezeigt. Du musst eine neue Anforderung für einen Gerätecode vornehmen.
    unsupported_grant_typeDer Gewährungstyp muss urn:ietf:params:oauth:grant-type:device_code sein und als Eingabeparameter enthalten sein, wenn Sie die OAuth-Tokenanforderung POST http(s)://HOSTNAME/login/oauth/access_token abfragen.
    incorrect_client_credentialsFür den Gerätefluss musst du die Client-ID deiner App übergeben, die du auf der Seite „Einstellungen“ deiner App findest. Die Client-ID unterscheidet sich von der App-ID und dem geheimen Clientschlüssel.
    incorrect_device_codeDer bereitgestellte device_code ist ungültig.
    access_deniedWenn Benutzerinnen während des Autorisierungsprozesses auf „Abbrechen“ klicken, wird ein access_denied-Fehler angezeigt, und die Benutzerinnen können den Überprüfungscode nicht noch einmal verwenden.
    device_flow_disabledDer Gerätefluss wurde in den Einstellungen der App nicht aktiviert. Weitere Informationen zum Aktivieren des Geräteflusses findest du unter Ändern einer GitHub-App-Registrierung.
  5. Nach der Eingabe des user_code durch die Benutzer*innen antwortet GitHub mit einer Antwort, die die folgenden Abfrageparameter enthält:

    AntwortparametertypeBeschreibung
    access_tokenstringDas Benutzerzugriffstoken. Das Token beginnt mit ghu_.
    expires_inintegerDie Anzahl der Sekunden bis zum Ablauf des access_token. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Der Wert ist immer 28800 (8 Stunden).
    refresh_tokenstringDas Aktualisierungstoken. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Das Token beginnt mit ghr_.
    refresh_token_expires_inintegerDie Anzahl der Sekunden bis zum Ablauf des refresh_token. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Der Wert ist immer 15897600 (6 Monate).
    scopestringDie Bereiche für das Token. Dieser Wert ist immer eine leere Zeichenfolge. Im Gegensatz zu einem herkömmlichen OAuth-Token ist das Benutzerzugriffstoken auf die Berechtigungen beschränkt, die sowohl deiner App als auch den Benutzer*innen zugewiesen wurden.
    token_typestringDer Tokentyp. Der Wert ist immer bearer.
  6. Verwende das Benutzerzugriffstoken aus dem vorherigen Schritt, um API-Anforderungen im Namen von Benutzer*innen auszuführen. Schließe das Benutzerzugriffstoken in den Authorization-Header einer API-Anforderung ein. Zum Beispiel:

    curl --request GET \
    --url "http(s)://HOSTNAME/api/v3/user" \
    --header "Accept: application/vnd.github+json" \
    --header "Authorization: Bearer USER_ACCESS_TOKEN" \
    --header "X-GitHub-Api-Version: 2022-11-28"
    

Generieren eines Benutzerzugriffstokens, wenn Benutzer*innen deine App installieren

Wenn du in den App-Einstellungen Benutzerautorisierung während der Installation anfordern (OAuth) auswählst, startet GitHub den Webanwendungsfluss sofort, nachdem Benutzer*innen deine App installiert haben.

Du kannst mit dieser Methode ein Benutzerzugriffstoken generieren, unabhängig davon, ob die App unter einem Benutzerkonto oder einem Organisationskonto installiert ist. Wenn die App jedoch unter einem Organisationskonto installiert wurde, musst du den Webanwendungsfluss oder den Gerätefluss verwenden, um ein Benutzerzugriffstoken für andere Benutzer*innen in der Organisation zu generieren.

  1. Wenn Benutzer*innen deine App installiert, leitet GitHub sie zu http(s)://HOSTNAME/login/oauth/authorize?client_id=CLIENT_ID um, wobei CLIENT_ID die Client-ID deiner App ist.

  2. Wenn die Benutzer*innen deine Autorisierungsanforderung akzeptieren, leitet GitHub sie zur ersten Rückruf-URL in deinen App-Einstellungen um und stellt einen code-Abfrageparameter bereit.

    Wenn du festlegen möchtest, welche Rückruf-URL verwendet wird, wählst du Benutzerautorisierung während der Installation anfordern (OAuth) nicht aus. Führe die Benutzer*innen stattdessen durch den vollständigen Webanwendungsfluss, und gib den redirect_uri-Parameter an.

  3. Tausche das code-Element aus dem vorherigen Schritt gegen ein Benutzerzugriffstoken aus, indem du eine POST-Anforderung an diese URL sendest und dabei folgende Abfrageparameter angibst: http(s)://HOSTNAME/login/oauth/access_token

    Query parameter (Abfrageparameter)typeBESCHREIBUNG
    client_idstringErforderlich. Die Client-ID für deine GitHub App. Die Client-ID unterscheidet sich von der App-ID. Du findest die Client-ID auf der Einstellungsseite deiner App. Weitere Informationen zum Aufrufen der Einstellungsseite für deine GitHub App findest du unter Ändern einer GitHub-App-Registrierung.
    client_secretstringErforderlich. Der geheime Clientschlüssel für deine GitHub App. Du kannst einen geheimen Clientschlüssel auf der Einstellungsseite für deine App generieren.
    codestringErforderlich. Der Code, den du im vorherigen Schritt erhalten hast.
    redirect_uristringDie URL in der Anwendung, an die Benutzer nach der Autorisierung gesendet werden. Diese muss genau mit einer der URLs übereinstimmen, die du beim Einrichten deiner GitHub App als „Rückruf-URL“ angegeben hast. Sie darf keine zusätzlichen Parameter enthalten.
    repository_idstringDie ID eines einzelnen Repositorys, auf das das Benutzerzugriffstoken zugreifen kann. Wenn die GitHub App oder dieder Benutzerin nicht auf das Repository zugreifen kann, wird dies ignoriert. Verwende diesen Parameter, um den Zugriff auf das Benutzerzugriffstoken weiter einzuschränken.
  4. GitHub gibt eine Antwort, die folgende Parameter enthält:

    AntwortparametertypeBeschreibung
    access_tokenstringDas Benutzerzugriffstoken. Das Token beginnt mit ghu_.
    expires_inintegerDie Anzahl der Sekunden bis zum Ablauf des access_token. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Der Wert ist immer 28800 (8 Stunden).
    refresh_tokenstringDas Aktualisierungstoken. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Das Token beginnt mit ghr_.
    refresh_token_expires_inintegerDie Anzahl der Sekunden bis zum Ablauf des refresh_token. Wenn du den Ablauf von Benutzerzugriffstoken deaktiviert hast, wird dieser Parameter ausgelassen. Der Wert ist immer 15897600 (6 Monate).
    scopestringDie Bereiche für das Token. Dieser Wert ist immer eine leere Zeichenfolge. Im Gegensatz zu einem herkömmlichen OAuth-Token ist das Benutzerzugriffstoken auf die Berechtigungen beschränkt, die sowohl deiner App als auch den Benutzer*innen zugewiesen wurden.
    token_typestringDer Tokentyp. Der Wert ist immer bearer.
  5. Verwende das Benutzerzugriffstoken aus dem vorherigen Schritt, um API-Anforderungen im Namen von Benutzer*innen auszuführen. Schließe das Benutzerzugriffstoken in den Authorization-Header einer API-Anforderung ein. Zum Beispiel:

    curl --request GET \
    --url "http(s)://HOSTNAME/api/v3/user" \
    --header "Accept: application/vnd.github+json" \
    --header "Authorization: Bearer USER_ACCESS_TOKEN" \
    --header "X-GitHub-Api-Version: 2022-11-28"
    

Verwenden eines Aktualisierungstokens zum Generieren eines Benutzerzugriffstokens

Standardmäßig laufen Benutzerzugriffstoken nach 8 Stunden ab. Wenn du ein Benutzerzugriffstoken mit einer Ablaufzeit empfängst, erhältst du auch ein Aktualisierungstoken. Das Aktualisierungstoken läuft nach 6 Monaten ab. Du kannst dieses Aktualisierungstoken verwenden, um ein Benutzerzugriffstoken erneut zu generieren. Weitere Informationen findest du unter Aktualisieren von Benutzerzugriffstoken.

GitHub empfiehlt dringend, ablaufende Benutzerzugriffstoken zu verwenden. Wenn du dich zuvor gegen die Verwendung von ablaufenden Benutzerzugriffstoken entschieden hast, aber dieses Feature nun aktivieren möchtest, findest du unter Aktivieren optionaler Features für GitHub-Apps weitere Informationen.

Problembehandlung

In den folgenden Abschnitten werden einige Fehler beschrieben, die beim Generieren eines Benutzerzugriffstokens auftreten können.

Falsche Clientanmeldeinformationen

Wenn die von dir angegebenen Werte für client_id oder client_secret falsch sind, wird der Fehler incorrect_client_credentials angezeigt.

Um diesen Fehler zu beheben, stelle sicher, dass du die richtigen Anmeldeinformationen für deine GitHub App verwendest. Du findest die Client-ID und den geheimen Clientschlüssel auf der Einstellungsseite für deine GitHub App. Weitere Informationen zum Aufrufen der Einstellungsseite für deine GitHub App findest du unter Ändern einer GitHub-App-Registrierung.

Konflikt des Umleitungs-URIs

Wenn du einen Umleitungs-URI (redirect_uri) angibst, der keiner der Rückruf-URLs in deiner GitHub App-Registrierung entspricht, wird der Fehler redirect_uri_mismatch angezeigt.

Um diesen Fehler zu beheben, gib entweder einen Umleitungs-URI (redirect_uri) an, der einer der Rückruf-URLs für deine GitHub App-Registrierung entspricht, oder lasse diesen Parameter aus, um standardmäßig die erste Rückruf-URL zu verwenden, die in deiner GitHub App-Registrierung aufgeführt ist. Weitere Informationen findest du unter Informationen zur Rückruf-URL für die Benutzerautorisierung.

Fehlerhafter Überprüfungscode

Wenn du den Gerätefluss verwendest und der von dir angegebene Überprüfungscode (device_code) falsch oder abgelaufen ist oder nicht mit dem Wert übereinstimmt, den du von der anfänglichen Anforderung an http(s)://HOSTNAME/login/device/code erhalten hast, wird der Fehler bad_verification_code angezeigt.

Um diesen Fehler zu beheben, musst du den Gerätefluss erneut starten, um einen neuen Code zu erhalten. Weitere Informationen findest du unter Verwenden des Geräteflusses zum Generieren eines Benutzerzugriffstokens.

Ungültiges Aktualisierungstoken

Wenn das von dir angegebene Aktualisierungstoken ungültig oder abgelaufen ist, wird der Fehler bad_refresh_token angezeigt.

Um diesen Fehler zu beheben, musst du den Webanwendungsfluss oder den Gerätefluss neu starten, um ein neues Benutzerzugriffstoken und Aktualisierungstoken zu erhalten. Du erhältst nur dann ein Aktualisierungstoken, wenn für deine GitHub App der Ablauf von Benutzerzugriffstoken aktiviert wurde. Weitere Informationen findest du unter Aktualisieren von Benutzerzugriffstoken.

Nicht unterstützter Gewährungstyp

Wenn du ein Benutzerzugriffstoken über den Gerätefluss anforderst, muss der Parameter grant_type auf urn:ietf:params:oauth:grant-type:device_code festgelegt sein. Wenn du ein Benutzerzugriffstoken mithilfe eines Aktualisierungstoken aktualisierst, muss der Parameter grant_type auf refresh_token festgelegt sein. Wenn du nicht den richtigen Gewährungstyp verwendest, wird der Fehler unsupported_grant_type angezeigt.

Nicht überprüfte Benutzer-E-Mail-Adresse

Wenn der Benutzer oder die Benutzerin, für den bzw. die du ein Benutzerzugriffstoken generieren möchtest, seine bzw. ihre primäre E-Mail-Adresse nicht mit GitHub überprüft hat, wird der Fehler unverified_user_email angezeigt.

Um diesen Fehler zu beheben, fordere den Benutzer bzw. die Benutzerin auf, die primäre E-Mail-Adresse für das GitHub-Konto zu überprüfen. Weitere Informationen findest du in der Dokumentation zu GitHub Free unter Deine E-Mail-Adresse verifizieren.