Bereiche für OAuth-Apps

Beim Einrichten einer OAuth-App auf GitHub werden dem Benutzer angeforderte Bereiche im Autorisierungsformular angezeigt.

Wenn deine OAuth App keinen Zugriff auf einen Browser hat, z. B. ein CLI-Tool, musst du keinen Bereich für Benutzer angeben, damit diese sich bei der App authentifizieren können. Weitere Informationen findest du unter Autorisieren von OAuth-Apps.

Überprüfe Kopfzeilen, um festzustellen, über welche OAuth-Bereiche du verfügst und was von der API-Aktion akzeptiert wird:

$ curl -H "Authorization: Bearer OAUTH-TOKEN" https://api.github.com/users/codertocat -I
HTTP/2 200
X-OAuth-Scopes: repo, user
X-Accepted-OAuth-Scopes: user

• X-OAuth-Scopes listet die Bereiche auf, die dein Token autorisiert hat.
• X-Accepted-OAuth-Scopes enthält die Bereiche, auf die durch die Aktion geprüft wird.

Verfügbare Bereiche

Name | Beschreibung -----|-----------| (no scope) | Gewährt schreibgeschützten Zugriff auf öffentliche Informationen (einschließlich Benutzerprofilinformationen, Repositoryinformationen und Gists) repo | Gewährt vollen Zugriff auf öffentliche und private Repositorys, einschließlich Lese- und Schreibzugriff auf Code, Commitstatus, Repositoryeinladungen, Mitarbeiterinnen, Bereitstellungsstatus und Repositorywebhooks. Hinweis: Zusätzlich zu repositorybezogenen Ressourcen gewährt der repo-Bereich auch Zugriff auf die Verwaltung von organisationseigenen Ressourcen, einschließlich Projekten, Einladungen, Teammitgliedschaften und Webhooks. Dieser Bereich gewährt auch die Möglichkeit, Projekte im Besitz von Benutzerinnen zu verwalten.  repo:status| Gewährt Lese-/Schreibzugriff auf Commitstatus in öffentlichen und privaten Repositorys. Dieser Bereich ist nur dafür erforderlich, anderen Benutzern oder Diensten Zugriff auf Commitstatus privater Repositorys zu gewähren, ohne Zugriff auf den Code zu gewähren.  repo_deployment| Gewährt Zugriff auf Bereitstellungsstatus für öffentliche und private Repositorys. Dieser Bereich ist nur dafür erforderlich, anderen Benutzern oder Diensten Zugriff auf Bereitstellungsstatus zu gewähren, ohne Zugriff auf den Code zu gewähren.  public_repo| Beschränkt den Zugriff auf öffentliche Repositorys. Das umfasst Lese-/Schreibzugriff auf Code, Commitstatus, Repositoryprojekte, Projektmitarbeiter und Bereitstellungsstatus für öffentliche Repositorys und Organisationen. Auch dafür erforderlich, öffentliche Repositorys mit Sternen zu versehen.  repo:invite | Gewährt die Möglichkeit zum Akzeptieren/Ablehnen von Einladungen zur Zusammenarbeit an einem Repository. Dieser Bereich ist nur dafür erforderlich, anderen Benutzern oder Diensten Zugriff auf Einladungen zu gewähren, ohne Zugriff auf den Code zu gewähren.  security_events | Gewährt:
Lese- und Schreibzugriff auf sicherheitsrelevante Ereignisse in der code scanning-API
Dieser Bereich ist nur dafür erforderlich, anderen Benutzern oder Diensten Zugriff auf sicherheitsrelevante Ereignisse zu gewähren, ohne Zugriff auf den Code zu gewähren. admin:repo_hook | Gewährt Lese-, Schreib-, Ping- und Löschzugriff auf Repositoryhooks in öffentlichen oder privaten Repositorys. Der repo- und der public_repo-Bereich gewähren vollständigen Zugriff auf Repositorys, einschließlich Repositoryhooks. Verwende den Bereich admin:repo_hook, um den Zugriff ausschließlich auf Repositoryhooks zu beschränken.  write:repo_hook| Gewährt Lese-, Schreib- und Pingzugriff auf Hooks in öffentlichen oder privaten Repositorys.  read:repo_hook| Gewährt Lese- und Pingzugriff auf Hooks in öffentlichen oder privaten Repositorys. admin:org | Verwalte die Organisation und ihre Teams, Projekte und Mitgliedschaften vollständig.  write:org| Lese- und Schreibzugriff auf Organisationsmitgliedschaft, Organisationsprojekte und Teammitgliedschaft.  read:org| Schreibgeschützter Zugriff auf Organisationsmitgliedschaft, Organisationsprojekte und Teammitgliedschaft. admin:public_key | Verwalte öffentliche Schlüssel vollständig.  write:public_key| Erstelle Details für öffentliche Schlüssel, liste sie auf, und zeige sie an.  read:public_key| Liste Details für öffentliche Schlüssel auf, und zeige sie an. admin:org_hook | Gewährt Lese-, Schreib-, Ping- und Löschzugriff auf Organisationshooks. Hinweis: OAuth-Token können diese Aktionen nur mit Organisationshooks ausführen, die von der OAuth-App erstellt wurden. Über ein Personal access token kann diese Aktionen nur für Organisationshooks ausgeführt werden, die von einem Benutzer erstellt wurden. gist | Gewährt Schreibzugriff auf Gists. notifications | Gewährt:
Lesezugriff auf die Benachrichtigungen eines Benutzers
Markieren als Lesezugriff auf Threads
Überwachen des Zugriffs auf ein Repository, Beenden des Überwachens des Zugriffs auf ein Repository und
Lese-, Schreib- und Löschzugriff auf Threadabonnements. user | Gewährt nur Lese-/Schreibzugriff auf Profilinformationen. Beachte, dass dieser Bereich user:email und user:follow umfasst.  read:user| Gewährt Lesezugriff auf die Profildaten eines Benutzers.  user:email| Gewährt Lesezugriff auf die E-Mail-Adressen eines Benutzers.  user:follow| Gewährt Zugriff, um anderen Benutzerinnen zu folgen bzw. nicht mehr zu folgen. project | Gewährt Lese-/Schreibzugriff auf projects von Benutzerinnen und Organisation.  read:project| Gewährt Benutzer*innen und Organisationen schreibgeschützten Zugriff projects. delete_repo | Gewährt Löschzugriff auf der Administration unterliegende Repositorys. write:packages | Gewährt Zugriff zum Hochladen oder Veröffentlichen eines Pakets in GitHub Packages. Weitere Informationen findest du unter Veröffentlichen eines Pakets. read:packages | Gewährt Zugriff zum Herunterladen und Installieren von Paketen aus GitHub Packages Weitere Informationen findest du unter Installieren eines Pakets. delete:packages | Gewährt Zugriff zum Löschen von Paketen aus GitHub Packages Weitere Informationen findest du unter Löschen und Wiederherstellen eines Pakets. admin:gpg_key | Vollständige Verwaltung von GPG-Schlüsseln.  write:gpg_key| Erstelle Details für GPG-Schlüssel, liste sie auf, und zeige sie an.  read:gpg_key| Auflisten und Anzeigen von Details für GPG-Schlüssel. codespace | Gewährt die Möglichkeit, Codespaces zu erstellen und zu verwalten. Codespaces können ein GITHUB_TOKEN verfügbar machen, das möglicherweise andere Bereiche aufweist. Weitere Informationen findest du unter Sicherheit in GitHub Codespaces. workflow | Ermöglicht das Hinzufügen und Aktualisieren von GitHub Actions-Workflowdateien. Workflowdateien können ohne diesen Bereich committet werden, wenn dieselbe Datei (mit demselben Pfad und demselben Inhalt) in einem anderen Branch im selben Repository vorhanden ist. Workflowdateien können ein GITHUB_TOKEN verfügbar machen, das möglicherweise andere Bereiche aufweist. Weitere Informationen findest du unter Automatische Tokenauthentifizierung.

https://github.com/login/oauth/authorize?
  client_id=...&
  scope=user%20repo_deployment

Angeforderte Bereiche und gewährte Bereiche

Das Attribut scope enthält Bereiche, die dem Token zugeordnet sind und vom Benutzer gewährt wurden. Normalerweise sind diese Bereiche identisch mit den angeforderten. Benutzer können jedoch ihre Bereiche bearbeiten und deiner Anwendung effektiv weniger Zugriff gewähren, als du ursprünglich angefordert hast. Außerdem können Benutzer Tokenbereiche bearbeiten, nachdem der OAuth-Flow abgeschlossen wurde. Du solltest dir dieser Möglichkeit bewusst sein und das Verhalten deiner Anwendung entsprechend anpassen.

Es ist wichtig, Fehlerfälle zu behandeln, in denen dir ein Benutzer weniger Zugriff gewährt, als du ursprünglich angefordert hast. Von Anwendungen können die Benutzern z. B. gewarnt oder anderweitig informiert werden, dass der Funktionsumfang eingeschränkt wird oder dass sie einige Aktionen nicht ausführen können.

Die Benutzer können von den Anwendungen auch immer wieder durch den Flow zurückgeleitet werden, damit sie zusätzliche Berechtigungen erhalten. Denke aber immer daran, dass die Benutzer immer auch ablehnen können.

Unter Grundlagen des Authentifizierungshandbuchs findest du Tipps zur Behandlung von modifizierbaren Tokenbereichen.

Normalisierte Bereiche

Beim Anfordern mehrerer Bereiche wird das Token mit einer normalisierten Liste von Bereichen gespeichert. Dabei werden die Bereiche verworfen, die implizit in einem anderen angeforderten Bereich enthalten sind. Die Anforderung von user,gist,user:email führt z. B. zu einem Token mit den Bereichen user und gist, da der Zugriff, der mit dem Bereich user:email gewährt wird, im Bereich user enthalten ist.