Skip to main content
Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wurde eingestellt am 2023-03-15. 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. 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

Hinweis: Ablaufende Benutzerzugriffstoken sind derzeit ein optionales Feature und können Änderungen unterliegen. Informationen zum Aktivieren oder Deaktivieren des Tokenablauffeatures findest du unter Activating optional features for GitHub Apps. Weitere Informationen findest du unter Ablauf von Benutzer-zu-Server-Zugriffstoken für 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 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)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.

    Für benutzereigene Apps lautet die Einstellungsseite https://github.com/settings/apps/APP-SLUG.

    Für organisationseigene Apps lautet die Einstellungsseite https://github.com/organizations/ORGANIZATION/settings/apps/APP-SLUG.

    Ersetze APP-SLUG durch den mit Platzhaltern versehenen Namen deiner App und ORGANIZATION durch den mit Platzhaltern versehenen Namen deiner Organisation. Beispiel: https://github.com/organizations/octo-org/settings/apps/octo-app.
    redirect_uristringDie 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.
    statestringBei der Angabe sollte zum Schutz vor Fälschungsangriffen eine zufällige Zeichenfolge eingefügt werden. Sie kann auch andere beliebige Daten enthalten.
    loginstringWenn 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_signupbooleanGibt 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.

    Für benutzereigene Apps lautet die Einstellungsseite https://github.com/settings/apps/APP-SLUG.

    Für organisationseigene Apps lautet die Einstellungsseite https://github.com/organizations/ORGANIZATION/settings/apps/APP-SLUG.

    Ersetze APP-SLUG durch den mit Platzhaltern versehenen Namen deiner App und ORGANIZATION durch den mit Platzhaltern versehenen Namen deiner Organisation. Beispiel: https://github.com/organizations/octo-org/settings/apps/octo-app.
    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 15811200 (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"

Verwenden des Geräteflusses zum Generieren eines Benutzerzugriffstokens

Hinweis: Der Gerätefluss befindet sich in der öffentlichen Betaversion 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.

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.

    • Für benutzereigene Apps lautet die Einstellungsseite https://github.com/settings/apps/APP-SLUG.
    • Für organisationseigene Apps lautet die Einstellungsseite https://github.com/organizations/ORGANIZATION/settings/apps/APP-SLUG.

    Ersetze APP-SLUG durch den mit Platzhaltern versehenen Namen deiner App und ORGANIZATION durch den mit Platzhaltern versehenen Namen deiner Organisation. Beispiel: https://github.com/organizations/octo-org/settings/apps/octo-app.

  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 du die OAuth-Tokenanforderung POST http(s)://HOSTNAME/login/oauth/access_token abfragst.
    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.
  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 15811200 (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"

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.

    Für benutzereigene Apps lautet die Einstellungsseite https://github.com/settings/apps/APP-SLUG.

    Für organisationseigene Apps lautet die Einstellungsseite https://github.com/organizations/ORGANIZATION/settings/apps/APP-SLUG.

    Ersetze APP-SLUG durch den mit Platzhaltern versehenen Namen deiner App und ORGANIZATION durch den mit Platzhaltern versehenen Namen deiner Organisation. Beispiel: https://github.com/organizations/octo-org/settings/apps/octo-app.
    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 15811200 (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"

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 Activating optional features for GitHub Apps weitere Informationen.

Unterstützte Endpunkte für Benutzerzugriffstoken

Überprüfungsausführungen

Prüfsuiten

Verhaltensregeln

Bereitstellungsstatus

Bereitstellungen

Ereignisse

Feeds

Git-Blobs

Git-Commits

Git-Verweise

Git-Tags

Git-Strukturen

Gitignore-Vorlagen

Installationen

Issues zugewiesene Personen

Issue-Kommentare

Issue-Ereignisse

Issue-Zeitachse

Probleme

Bezeichnungen

Lizenzen

Markdown

Meta

Meilensteine

Organisationshooks

Organisationsmitglieder

Projektmitarbeiter außerhalb der Organisation

Pre-Receive-Hooks für eine Organisation

Teamprojekte einer Organisation

Teamrepositorys einer Organisation

Organisationsteams

Organisationen

Projektmitarbeiter

Projekte

Pullkommentare

Überprüfungsereignisse für Pull Requests

Überprüfungsanforderungen für Pull Requests

Prüfer von Pull Requests

Pulls

Reaktionen

Repositorys

Repositoryaktivität

Repositorybranches

Projektmitarbeiter für Repositorys

Commitkommentare für Repositorys

Repositorycommits

Repositorycommunity

Repositoryinhalte

Repositoryereignisdispatches

Repositoryhooks

Repositoryeinladungen

Repositoryschlüssel

Repositoryseiten

Pre-Receive-Hooks für Repository

Repositoryreleases

Repositorystatistiken

Root

Status

Teamdiskussionen

Themen

Benutzer-E-Mails

Benutzerfollower

Benutzer-GPG-Schlüssel

Öffentliche Schlüssel für Benutzer

Benutzer