Verwalten deiner persönlichen Zugriffstoken

Informationen über personal access token

          Personal access tokens sind eine Alternative zur Verwendung von Kennwörtern für die Authentifizierung GitHub bei Verwendung der [GitHub API](/rest/overview/authenticating-to-the-rest-api) oder der [Befehlszeile](#using-a-personal-access-token-on-the-command-line).

          Personal access tokens sind für den Zugriff auf GitHub Ressourcen im eigenen Auftrag vorgesehen. Für den Zugriff auf Ressourcen im Namen einer Organisation oder für langlebige Integrationen sollten Sie eine GitHub App. Weitere Informationen finden Sie unter [AUTOTITLE](/apps/creating-github-apps/setting-up-a-github-app/about-creating-github-apps).

          Ein Token verfügt über die gleichen Funktionen für den Zugriff auf Ressourcen und zum Ausführen von Aktionen für diese Ressourcen, über die der Besitzer des Tokens verfügt. Er ist zudem durch alle Bereiche oder Berechtigungen beschränkt, die dem Token zugewiesen werden. Ein Token kann einem Benutzer keine zusätzlichen Zugriffsfunktionen gewähren. Beispielsweise kann ein personal access token Token mit einem `admin:org` Bereich konfiguriert werden, aber wenn der Besitzer des Tokens kein Organisationsbesitzer ist, erhält das Token keinen Administratorzugriff auf die Organisation.

personal access token-Typen

          GitHub unterstützt derzeit zwei Arten von personal access tokens: fine-grained personal access tokens und personal access tokens (classic). 
          GitHub empfiehlt, wann immer möglich fine-grained personal access tokens anstelle von personal access tokens (classic) zu verwenden.

Beides fine-grained personal access tokenund personal access tokens (classic) sind an den Benutzer gebunden, der sie generiert hat, und wird inaktiv, wenn der Benutzer den Zugriff auf die Ressource verliert.

Organisationsbesitzer können eine Richtlinie festlegen, um den Zugriff von personal access tokens (classic) auf ihre Organisation einzuschränken, und Unternehmensbesitzer können den Zugriff von personal access tokens (classic) auf das Unternehmen oder die Organisationen, die im Besitz des Unternehmens sind, einschränken. Weitere Informationen finden Sie unter Festlegen einer Richtlinie für persönliche Zugriffstoken für deine Organisation.

Fine-grained personal access tokens

          Fine-grained personal access tokens haben mehrere Sicherheitsvorteile gegenüber personal access tokens (classic), aber auch Einschränkungen, die Sie daran hindern können, sie in jedem Szenario zu verwenden. Diese Einschränkungen und unsere Pläne, sie zu beheben, findest du im [folgenden Abschnitt](#fine-grained-personal-access-tokens-limitations).

Wenn Sie für Ihr Szenario ein fine-grained personal access token verwenden können, profitieren Sie von diesen Verbesserungen:

• Jedes Token kann nur auf Ressourcen zugreifen, die einem einzelnen Benutzerkonto oder einer einzelnen Organisation gehören.
• Der Zugriff eines jeden Tokens kann weiter auf bestimmte Repositorys dieses Benutzerkontos oder dieser Organisation beschränkt werden.
• Jedem Token werden spezifische, differenzierte Berechtigungen gewährt, die mehr Kontrolle bieten als die Bereiche, die für personal access tokens (classic) gewährt werden.
• Organisationsbesitzer können eine Genehmigung für alle fine-grained personal access tokenBenutzer anfordern, die auf Ressourcen in der Organisation zugreifen können.
• Unternehmensbesitzer können eine Genehmigung für alle fine-grained personal access tokenBenutzer anfordern, die auf Ressourcen in Organisationen zugreifen können, die sich im Besitz des Unternehmens befinden.

Fine-grained personal access tokens Einschränkungen

          Fine-grained personal access tokens unterstützt nicht jedes Feature von personal access tokens (classic). Diese Featurelücken sind nicht dauerhaft - GitHub arbeiten daran, sie zu schließen. Weitere Informationen dazu, wann diese Szenarios unterstützt werden, findest du in [unserer öffentlichen Roadmap](https://github.com/github/roadmap).

Die wichtigsten Lücken in fine-grained personal access tokens sind:

• Wird fine-grained personal access token verwendet, um zu öffentlichen Repositorys beizutragen, bei denen der Benutzer kein Mitglied ist.

• Wird fine-grained personal access token verwendet, um zu Repositorys beizutragen, bei denen der Benutzer ein Externer oder Repositorymitarbeiter ist.

• Verwenden fine-grained personal access token , um gleichzeitig auf mehrere Organisationen zuzugreifen.

          * Verwenden von fine-grained personal access token zum Zugriff auf `internal` Ressourcen in einem Unternehmen, dem der Benutzer angehört.
  

• Wird fine-grained personal access token zum Aufrufen von APIs verwendet, die das Unternehmenskonto verwalten.

          * Verwendung fine-grained personal access token für den Zugriff auf Pakete.
  

• Wird fine-grained personal access token verwendet, um die Checks-API aufzurufen.

• Verwenden Sie fine-grained personal access token, um auf Projekte zuzugreifen, die einem Benutzerkonto gehören.

All diese Lücken werden im Laufe der Zeit gelöst, da GitHub sie weiterhin in sicherere Zugriffsmuster investieren.

Personal access tokens (classic)

Personal access tokens (classic) sind weniger sicher. Derzeit funktionieren einige Features jedoch nur mit personal access tokens (classic):

• Nur personal access tokens (classic) verfügen über Schreibzugriff für öffentliche Repositorys, die nicht dir gehören oder sich im Besitz einer Organisation befinden, der du nicht angehörst.
• Nur personal access tokens (classic) verfügen automatisch über Schreibzugriff für interne Repositorys, die sich im Besitz deines Unternehmens befinden. Fine-grained personal access token muss Zugriff auf interne Repositorys gewährt werden.
• Externe Projektmitarbeiter*innen können nur personal access tokens (classic) verwenden, um auf Organisationsrepositorys zuzugreifen, an denen sie mitwirken.
• Nur personal access tokens (classic) können auf Unternehmen zugreifen. (Fine-grained personal access token können auf Organisationen im Besitz von Unternehmen zugreifen.)
• Einige REST-API-Endpunkte sind nur mit einem personal access tokens (classic) verfügbar. Um zu überprüfen, ob ein Endpunkt auch fine-grained personal access token unterstützt, sieh in der Dokumentation für diesen Endpunkt nach, oder lies Endpunkte, die für feingranulare persönliche Zugriffstoken verfügbar sind.

Wenn Sie sich für die Verwendung eines personal access token (classic)Kontos entscheiden, denken Sie daran, dass sie Zugriff auf alle Repositorys innerhalb der Organisationen gewährt, auf die Sie Zugriff haben, sowie alle persönlichen Repositorys in Ihrem persönlichen Konto.

Schützen Ihrer personal access tokenDaten

          Personal access tokens sind wie Kennwörter, und sie teilen dieselben inhärenten Sicherheitsrisiken. Bevor Sie ein neues personal access token erstellen, sollten Sie überlegen, ob Ihnen eine sicherere Authentifizierungsmethode verfügbar ist.

• Um über die Befehlszeile auf GitHub zuzugreifen, können Sie GitHub CLI oder Git Credential Manager verwenden, anstatt ein personal access token zu erstellen.
• Wenn Sie eine personal access token in einem GitHub Actions Workflow verwenden, überlegen Sie, ob Sie stattdessen die integrierte GITHUB_TOKEN Funktion nutzen können. Weitere Informationen finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Wenn diese Optionen nicht möglich sind und Sie einen personal access tokenerstellen müssen, erwägen Sie die Verwendung eines anderen CLI-Diensts, um Ihr Token sicher zu speichern.

Wenn Sie ein personal access token in einem Skript verwenden, können Sie Ihr Token als Geheimnis speichern und Ihr Skript über GitHub Actions ausführen. Weitere Informationen finden Sie unter Verwenden von Geheimnissen in GitHub-Aktionen.

Weitere Informationen zu den Best Practices finden Sie unter Schützen deiner API-Anmeldeinformationen.

Erstellen eines fine-grained personal access token

1. Klicke in der oberen rechten Ecke einer Seite auf GitHub auf dein Profilbild und dann auf Settings.

2. Klicke in der linken Randleiste auf Developer settings.

3. Klicken Sie in der linken Randleiste unter Personal access tokens auf Feinkornierte Token.

4. Klicken Sie auf Neues Token generieren.

5. Gib unter Tokenname einen Namen für das Token ein.

6. Wählen unter Ablauf ein Ablaufdatum für das Token aus. Unbegrenzte Lebensdauern sind zulässig, können aber durch eine von Ihrer Organisation oder Ihrem Unternehmensbesitzer festgelegte Richtlinie für eine maximale Lebensdauer blockiert werden. Weitere Informationen finden Sie unter Durchsetzen einer Richtlinie für die Höchstlebensdauer für personal access tokens.

7. Füge optional unter Beschreibung eine Notiz hinzu, um den Zweck des Token zu beschreiben.

8. Wähle unter Ressourcenbesitzer einen Ressourcenbesitzerin aus. Das Token kann nur auf Ressourcen zugreifen, die dem oder der ausgewählten Ressourcenbesitzer*in gehören. Organisationen, bei denen Sie Mitglied sind, werden nicht angezeigt, wenn die Organisation die Verwendung von fine-grained personal access tokens blockiert hat. Weitere Informationen finden Sie unter Festlegen einer Richtlinie für persönliche Zugriffstoken für deine Organisation.

9. Falls optional der Ressourcenbesitzer eine Organisation ist, die Genehmigungen für fine-grained personal access token erfordert, geben Sie unter dem Ressourcenbesitzer im Feld eine Begründung für die Anfrage ein.

10. Wähle unter Repositoryzugriff die gewünschten Repositorys aus, auf die das Token zugreifen soll. Du solltest nur den mindestens erforderlichen Repositoryzugriff für deine Zwecke auswählen. Tokens beinhalten immer schreibgeschützten Zugriff auf alle öffentlichen Repositories auf GitHub.

11. Wenn du Nur ausgewählte Repositorys im vorherigen Schritt ausgewählt hast, wähle im Dropdownmenü Ausgewählte Repositorys die Repositorys aus, auf die du zugreifen möchtest.

12. Wähle unter Berechtigungen aus, welche Berechtigungen dem Token erteilt werden sollen. Je nachdem, welchen Ressourcenbesitzerin und welchen Repositoryzugriff du angegeben hast, gibt es Repository-, Organisations- und Kontoberechtigungen. Du solltest nur die mindestens erforderlichen Berechtigungen für deine Zwecke auswählen.

    Das REST-API-Referenzdokument für jeden Endpunkt gibt an, ob der Endpunkt mit fine-grained personal access tokens arbeitet und angibt, welche Berechtigungen erforderlich sind, damit das Token den Endpunkt verwenden kann. Einige Endpunkte erfordern möglicherweise mehrere Berechtigungen und einige möglicherweise eine von mehreren Berechtigungen. Eine Übersicht, auf welche REST-API-Endpunkte mit fine-grained personal access token jeder Berechtigung zugreifen können, finden Sie unter Erforderliche Berechtigungen für differenzierte persönliche Zugangstoken.

13. Klicke dann auf Token generieren.

Wenn Sie eine Organisation als Ressourcenbesitzer ausgewählt haben und die Organisation eine Genehmigung für fine-grained personal access token erfordert, wird Ihr Token als pending gekennzeichnet, bis es von einem Organisationsadministrator überprüft wird. Bis zur Genehmigung kann dein Token nur öffentliche Ressourcen lesen. Wenn du eine Inhaberin der Organisation bist, wird deine Anforderung automatisch genehmigt. Weitere Informationen finden Sie unter Überprüfen und Widerrufen persönlicher Zugriffstoken in deiner Organisation.

Vorausfüllen fine-grained personal access token von Detaildaten mithilfe von URL-Parametern

Sie können Vorlagen für eine fine-grained personal access token über Links freigeben. Wenn du Tokendetails auf diese Weise speicherst, lassen sich Workflows leichter automatisieren, und die Entwicklererfahrung wird verbessert, da die relevanten Felder bereits ausgefüllt sind, wenn Benutzende zur Tokenerstellung weitergeleitet werden.

Jedes unterstützte Feld kann mithilfe eines bestimmten Abfrageparameters festgelegt werden. Alle Parameter sind optional und werden vom Formular für die Tokengenerierung überprüft, um sicherzustellen, dass die Kombinationen von Berechtigungen und Ressourcenbesitzenden sinnvoll sind.

Die folgende URL-Beispielvorlage enthält Zeilenumbrüche, um die Lesbarkeit zu verbessern:

https://github.com/settings/personal-access-tokens/new
  ?name=Repo-reading+token
  &description=Just+contents:read
  &target_name=octodemo
  &expires_in=45
  &contents=read

https://github.com/settings/personal-access-tokens/new
  ?name=Repo-reading+token
  &description=Just+contents:read
  &target_name=octodemo
  &expires_in=45
  &contents=read

Probiere die URL aus, um ein Token mit contents:read und metadata:read, mit dem angegebenen Namen und der angegebenen Beschreibung sowie einem Ablaufdatum von 45 Tagen in der Zukunft zu erstellen. Es wird eine Fehlermeldung mit dem Hinweis Cannot find the specified resource owner: octodemo angezeigt, da du kein Mitglied der Organisation octodemo bist.

Im Folgenden sind einige Beispiel-URLs aufgeführt, die die am häufigsten verwendeten Token generieren:

• Lesen von Repositoryinhalten
• Pushzugriff auf Repositorys
• Zugriff auf GitHub-Modelle
• Aktualisieren von Code und Öffnen eines Pull Requests
• Verwalten von Copilot-Lizenzen innerhalb einer Organisation
• Copilot-Anfragen senden

Unterstützte Abfrageparameter

Halte dich an die Abfrageparameterdetails in der folgenden Tabelle, um eine eigene Tokenvorlage zu erstellen:

          `30` oder `none` | Ganze Zahl zwischen 1 und 366 oder `none` | Tage bis zum Ablauf oder `none` für „nicht ablaufend“. Wenn nicht angegeben, beträgt der Standardwert 30 Tage oder weniger, wenn für das Ziel eine Tokengültigkeitsdauer-Richtlinie festgelegt ist. |

| <permission> | Zeichenfolge | contents=read | Berechtigungsstufen und Zugriffsebenen | Die Berechtigungen, über die das Token verfügen soll. Berechtigungen können auf read, write oder admin festgelegt werden, aber nicht jede Berechtigung unterstützt jede dieser Ebenen. |

Berechtigungen

Jede unterstützte Berechtigung wird mit ihrem Namen als Abfrageparameter festgelegt, wobei der Wert die gewünschte Zugriffsebene angibt. Gültige Zugriffsebenen sind read, write und admin. Einige Berechtigungen unterstützen nur read, einige nur write, und nur einige wenige umfassen die Zugriffsebene admin. Verwende so viele Berechtigungen wie erforderlich (im Format &contents=read&pull_requests=write&...).

Du musst nicht sowohl read als auch write für eine Berechtigung in deine URL einschließen: write umfasst immer read, und admin umfasst immer write.

Kontoberechtigungen

Kontoberechtigungen werden nur verwendet, wenn die aktuelle benutzende Person als „Resource owner“ festgelegt ist.

          `read`, `write` |

| codespaces_user_secrets | Codespaces-Benutzergeheimnisse | read, write | | copilot_messages | Copilot-Chat | read | | copilot_editor_context | Copilot-Editor-Kontext | read | | copilot_requests | Copilot Anforderungen | write | | emails | E-Mail-Adressen | read, write | | user_events | Ereignisse | read | | followers | Follower | read, write | | gpg_keys | GPG-Schlüssel | read, write | | gists | Gists | write | | keys | Git-SSH-Schlüssel | read, write | | interaction_limits | Interaktionsgrenzwerte | read, write | | knowledge_bases | Wissensdatenbanken | read, write | | user_models | Modelle | read | | plan | Planen | read | | private_repository_invitations | Private Repository-Einladungen | read | | profile | Profil | write | | git_signing_ssh_public_keys | SSH-Signaturschlüssel | read, write | | starring | Versehen mit einem Stern | read, write | | watching | Watching (Überwachung) | read, write |

Repositoryberechtigungen

Repositoryberechtigungen funktionieren unabhängig davon, ob als „Resource Owner“ eine benutzende Person oder eine Organisation festgelegt ist.

          `read`, `write` |

| administration | Verwaltung | read, write | | | | attestations | Nachweise | read, write | | | | security_events | Codescanwarnungen | read, write | | codespaces | Codespaces | read, write | | codespaces_lifecycle_admin | Lebenszyklusverwaltung von Codespaces | read, write | | codespaces_metadata | Codespacemetadaten | read | | codespaces_secrets | Codespacegeheimnisse | write | | statuses | Commitstatus | read, write | | contents | Inhalt | read, write | | repository_custom_properties | Benutzerdefinierte Eigenschaften | read, write | | vulnerability_alerts | Dependabot-Warnungen | read, write | | dependabot_secrets | Dependabot-Geheimnisse | read, write | | deployments | Bereitstellungen | read, write | | discussions | Diskussionen | read, write | | environments | Umgebungen | read, write | | issues | Probleme | read, write | | merge_queues | Warteschlangen zusammenführen | read, write | | metadata | Metadaten | read | | pages | Seiten | read, write | | pull_requests | Pull Requests | read, write | | repository_advisories | Sicherheitsempfehlungen für Repositorys | read, write | | secret_scanning_alerts | Geheimnisüberprüfungswarnungen | read, write | | secrets | Geheimnisse | read, write | | actions_variables | Variablen | read, write | | repository_hooks | webhooks | read, write | | workflows | Workflows | write |

Organisationsberechtigungen

Organisationsberechtigungen können nur verwendet werden, wenn eine Organisation als „Resource Owner“ festgelegt ist.

          `read`, `write` |

| organization_user_blocking | Blockieren von Benutzern | read, write | | organization_campaigns | Kampagnen | read, write | | organization_custom_org_roles | Benutzerdefinierte Organisationsrollen | read, write | | organization_custom_properties | Benutzerdefinierte Repositoryeigenschaften | read, write``admin | | organization_custom_roles | Benutzerdefinierte Repositoryrollen | read, write | | organization_events | Ereignisse | read | | organization_copilot_seat_management | GitHub Copilot Business | read, write | | issue_types | Problemtypen | read, write | | organization_knowledge_bases | Wissensdatenbanken | read, write | | members | Mitglieder | read, write | | organization_models | Modelle | read | | organization_network_configurations | Netzwerkkonfigurationen | read, write | | organization_announcement_banners | Banner mit Ankündigungen der Organisation | read, write | | organization_codespaces | Organisationscodespaces | read, write | | organization_codespaces_secrets | Geheimnisse für Organisationscodespaces | read, write | | organization_codespaces_settings | Einstellungen für Organisationscodespaces | read, write | | organization_dependabot_secrets | Dependabot-Geheimnisse für Organisationen | read, write | | organization_code_scanning_dismissal_requests | Codeüberprüfung von Kündigungsanforderungen | read, write | | organization_private_registries | Private Registrierungen | read, write | | organization_plan | Planen | read | | organization_projects | Projekte | read, write``admin | | organization_secrets | Geheimnisse | read, write | | organization_self_hosted_runners | Selbstgehosteten Runnern | read, write | | team_discussions | Diskussionen im Team | read, write | | organization_actions_variables | Variablen | read, write | | organization_hooks | webhooks | read, write |

Erstellen eines personal access token (classic)

1. Klicke in der oberen rechten Ecke einer Seite auf GitHub auf dein Profilbild und dann auf Settings.

2. Klicke in der linken Randleiste auf Developer settings.

3. Klicken Sie in der linken Randleiste unter Personal access tokens auf Token (klassisch).

4. Wählen Sie Neues Token generieren aus und klicken Sie dann auf Neues Token generieren(klassisch).

5. Gib im Feld „Notiz“ einen aussagekräftigen Namen für das Token ein.

6. Wähle Ablauf und dann eine Standardoption aus, oder klicke auf Benutzerdefiniert, um ein Datum einzugeben.

7. Wähle die Berechtigungen aus, die du diesem Token erteilen möchtest. Um das Token für den Zugriff auf Repositorys über die Befehlszeile zu verwenden, wähle Repository aus. Ein Token ohne zugewiesene Bereiche kann nur auf öffentliche Informationen zugreifen. Weitere Informationen finden Sie unter Bereiche für OAuth-Apps.

8. Klicke dann auf Token generieren.

9. Wenn Sie das neue Token optional in die Zwischenablage kopieren möchten, klicken Sie auf .

          ![Screenshot der Seite "Personal access tokens". Neben einem verschwommenen Token wird ein Symbol mit zwei überlappenden Quadraten in orange umrandet.](/assets/images/help/settings/personal-access-tokens-ghes.png)
   

Löschen eines personal access token

Sie sollten eine personal access token löschen, wenn sie nicht mehr benötigt wird. Wenn Sie ein personal access token Element löschen, das zum Erstellen eines Bereitstellungsschlüssels verwendet wurde, wird der Bereitstellungsschlüssel ebenfalls gelöscht.

1. Klicke in der oberen rechten Ecke einer Seite auf GitHub auf dein Profilbild und dann auf Settings.

2. Klicke in der linken Randleiste auf Developer settings.

3. Klicken Sie in der linken Randleiste unter Personal access tokens entweder auf Feinkörnige Token oder Token (klassisch), je nachdem, welchen Typ personal access token Sie löschen möchten.

4. Klicken Sie rechts neben dem personal access token Zu löschenden Element auf "Löschen".

Verwendung von personal access token in der Befehlszeile

Sobald Sie über ein personal access tokenKennwort verfügen, können Sie es anstelle Ihres Kennworts eingeben, wenn Git-Vorgänge über HTTPS ausgeführt werden.

Um beispielsweise ein Repository über die Befehlszeile zu klonen, gibst du den folgenden git clone-Befehl ein. Dann wirst du aufgefordert, deinen Benutzernamen und dein Kennwort einzugeben. Wenn Sie zur Eingabe Ihres Kennworts aufgefordert werden, geben Sie Ihr personal access token anstelle eines Kennworts ein.

$ git clone https://HOSTNAME/USERNAME/REPO.git
Username: YOUR-USERNAME
Password: YOUR-PERSONAL-ACCESS-TOKEN

Obwohl Sie Ihren Benutzernamen zusammen mit Ihrem personal access tokenBenutzernamen eingeben müssen, wird der Benutzername nicht verwendet, um Sie zu authentifizieren. Stattdessen wird personal access token verwendet, um Sie zu authentifizieren. Wenn Sie keinen Benutzernamen eingeben, erhalten Sie eine Fehlermeldung darüber, dass Ihre Anmeldeinformationen ungültig sind.

          Personal access tokens kann nur für HTTPS-Git-Vorgänge verwendet werden. Wenn dein Repository eine SSH-Remote-URL verwendet, musst du [das Remoterepository von SSH auf HTTPS umstellen](/get-started/git-basics/managing-remote-repositories#switching-remote-urls-from-ssh-to-https).

Wenn du nicht nach einem Benutzernamen und einem Passwort gefragt wirst, wurden deine Anmeldeinformationen möglicherweise auf deinem Computer zwischengespeichert. Du kannst deine Anmeldeinformationen in der Keychain aktualisieren, um das alte Kennwort durch das Token zu ersetzen.

Anstatt Ihr personal access token für jeden HTTPS-Git-Vorgang manuell einzugeben, können Sie Ihr personal access token mit einem Git-Client zwischenspeichern. Git speichert deine Anmeldeinformationen vorübergehend im Arbeitsspeicher, bis ein Ablaufintervall abgelaufen ist. Du kannst das Token auch in einer Nur-Textdatei speichern, die Git vor jeder Anforderung lesen kann. Weitere Informationen finden Sie unter Zwischenspeichern Ihrer GitHub Anmeldeinformationen in Git.

Weiterführende Themen

• Informationen zur Authentifizierung für GitHub
• Tokenexpirierung und Widerruf