{"meta":{"title":"Best Practices beim Erstellen einer OAuth-App","intro":"Befolgen Sie diese bewährten Vorgehensweisen, um die Sicherheit und Leistung Ihres OAuth app zu verbessern.","product":"Apps","breadcrumbs":[{"href":"/de/apps","title":"Apps"},{"href":"/de/apps/oauth-apps","title":"OAuth-Apps"},{"href":"/de/apps/oauth-apps/building-oauth-apps","title":"Erstellen von OAuth-Apps"},{"href":"/de/apps/oauth-apps/building-oauth-apps/best-practices-for-creating-an-oauth-app","title":"Bewährte Methoden"}],"documentType":"article"},"body":"# Best Practices beim Erstellen einer OAuth-App\n\nBefolgen Sie diese bewährten Vorgehensweisen, um die Sicherheit und Leistung Ihres OAuth app zu verbessern.\n\n## Verwenden Sie stattdessen eine GitHub App\n\nWenn möglich, erwägen Sie die Verwendung einer GitHub App anstelle eines OAuth app. Im Allgemeinen werden GitHub Apps gegenüber OAuth apps bevorzugt.\nGitHub Apps Verwenden Sie differenzierte Berechtigungen, geben Sie dem Benutzer mehr Kontrolle darüber, auf welche Repositorys die App zugreifen kann, und verwenden Sie kurzlebige Token. Diese Eigenschaften können die Sicherheit der App erhöhen, indem sie den Schaden begrenzen, der verursacht werden könnte, wenn die Anmeldeinformationen der App kompromittiert werden.\n\nÄhnlich wie OAuth apps kann GitHub Apps weiterhin OAuth 2.0 verwenden, eine Art von OAuth-Token (als Zugriffstoken bezeichnet) erzeugen und im Namen eines Benutzers Aktionen ausführen.\nGitHub Apps Kann jedoch auch unabhängig von einem Benutzer handeln.\n\nWeitere Informationen zu GitHub Apps findest du unter [Informationen zum Erstellen von GitHub Apps](/de/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps).\n\nWeitere Informationen zur Migration eines vorhandenen OAuth app zu einem GitHub App finden Sie unter [Migrieren von OAuth-Apps zu GitHub Apps](/de/apps/creating-github-apps/about-creating-github-apps/migrating-oauth-apps-to-github-apps).\n\n## Minimale Geltungsbereiche verwenden\n\nSie OAuth app sollten nur die Bereiche anfordern, die die App benötigt, um ihre beabsichtigte Funktionalität auszuführen. Wenn Token für deine App kompromittiert werden, lässt sich damit der mögliche Schaden begrenzen. Weitere Informationen finden Sie unter [Autorisieren von OAuth-Apps](/de/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps).\n\n## Autorisieren Sie gründlich und dauerhaft\n\nNach der Anmeldung bei einem Benutzer müssen App-Entwickler zusätzliche Schritte ausführen, um sicherzustellen, dass der Benutzer Zugriff auf die Daten in Ihrem System haben soll. Für jede Anmeldung sind neue Überprüfungen ihrer Mitgliedschaften, des Zugriffs und des aktuellen SSO-Status erforderlich.\n\n### Verwenden Sie den dauerhaften, eindeutigen `id`, um den Benutzer zu speichern.\n\nWenn sich ein Benutzer anmeldet und Aktionen in Ihrer Anwendung ausführt, müssen Sie sich merken, welcher Benutzer diese Aktion ausgeführt hat, um ihm beim nächsten Anmelden Zugriff auf dieselben Ressourcen zu gewähren.\n\nUm Benutzer in Ihrer Datenbank korrekt zu speichern, verwenden Sie immer den `id` des Benutzers. Dieser Wert ändert sich niemals für den Benutzer oder wird verwendet, um auf einen anderen Benutzer zu verweisen, sodass sichergestellt wird, dass Sie Zugriff auf den gewünschten Benutzer gewähren. Sie können den `id` eines Benutzers mit dem REST-API-Endpunkt `GET /user` finden. Weitere Informationen findest du unter [REST-API-Endpunkte für Benutzer](/de/rest/users/users#get-a-user).\n\nWenn Sie Verweise auf Repositorys, Organisationen und Unternehmen speichern, verwenden Sie auch ihre `id`, um sicherzustellen, dass Ihre Links zu ihnen korrekt bleiben.\n\nVerwenden Sie *niemals* Bezeichner, die sich im Laufe der Zeit ändern können, einschließlich Benutzerhandles, Organisations-Slugs oder E-Mail-Adressen.\n\n### Überprüfen des Organisationszugriffs bei jeder neuen Authentifizierung\n\nWenn du dich einen Benutzer anmeldest, solltest du nachverfolgen, für welche Organisationen das Token des Benutzers autorisiert ist. Dies kann sich im Laufe der Zeit ändern, nachdem „Anmelden als“-Benutzer von Organisationen entfernt wurden. Wenn eine Organisation SAML SSO verwendet und ein Benutzer oder eine Benutzerin SAML SSO nicht ausgeführt hat, wird das Benutzerzugriffstoken keinen Zugriff auf diese Organisation haben. Du solltest den `GET /user/installations`-REST-API-Endpunkt regelmäßig verwenden, um zu überprüfen, auf welche Organisationen ein Benutzerzugriffstoken Zugriff hat. Wenn der Benutzer nicht berechtigt ist, auf eine Organisation zuzugreifen, solltest du den Zugriff auf unternehmenseigene Daten in deiner eigenen Anwendung verhindern, bis er SAML SSO durchführt oder der Organisation erneut beitritt. Weitere Informationen finden Sie unter [REST-API-Endpunkte für GitHub App Installationen](/de/rest/apps/installations#list-app-installations-accessible-to-the-user-access-token).\n\n### Speichern von Benutzerdaten mit Organisations- und Unternehmenskontexten\n\nÜber das Nachverfolgen der Benutzeridentität über das `id` Feld hinaus sollten Sie Daten für die Organisation oder das Unternehmen aufbewahren, unter denen jeder Benutzer arbeitet. Dadurch wird sichergestellt, dass keine vertraulichen Informationen verloren gehen, wenn ein Benutzer die Rolle wechselt.\n\nZum Beispiel:\n\n1. Ein Benutzer befindet sich in der `Mona` Organisation, für die SAML SSO erforderlich ist, und meldet sich nach dem Ausführen von SSO bei Ihrer App an. Ihre App hat nun Zugriff auf alles, was der Benutzer in `Mona` tut.\n2. Der Benutzer zieht einen Haufen Code aus einem Repository in `Mona` und speichert ihn in Ihrer Anwendung zur Analyse.\n3. Später wechselt der Benutzer Aufträge und wird aus der `Mona` Organisation entfernt.\n\nWenn der Benutzer auf Ihre Anwendung zugreift, kann er dann immer noch den Code und die Analysen der `Mona` Organisation in seinem Benutzerkonto sehen?\n\nAus diesem Grund ist es wichtig, die Quelle der Daten zu verfolgen, die Ihre App speichert. Andernfalls ist Ihre App eine Datenschutzbedrohung für Organisationen, und sie werden Ihre App wahrscheinlich verbieten, wenn sie nicht vertrauen können, dass Ihre App ihre Daten ordnungsgemäß schützt.\n\n### Bestätigen des Zugriffs eines Benutzers auf Ihre App\n\nOAuth-App von Benutzern außerhalb Ihrer Organisation oder Ihres Unternehmens zugegriffen werden. Wenn Sie möchten, dass eine App nur von Mitgliedern Ihrer Organisation oder Ihres Unternehmens verwendet wird, sollten Sie den Mitgliedschaftsstatus des Benutzers überprüfen, wenn sich der Benutzer bei Ihrer App anmeldet.\n\nUm die Liste der Organisationen zu finden, in denen ein Benutzer Mitglied ist, können Sie den Endpunkt „Organisationen für den authentifizierten Benutzer auflisten“ verwenden. Anschließend können Sie diese Liste mit einer Liste der für Ihre App zugelassenen Organisationen abgleichen. Weitere Informationen finden Sie unter [REST-API-Endpunkte für Organisationen](/de/rest/orgs/orgs#list-organizations-for-the-authenticated-user).\n\n## Schütze die Anmeldeinformationen deiner App\n\nMit einem geheimen Clientschlüssel und dem Autorisierungscode eines Benutzers kann sich Ihre App bei einem Benutzer anmelden und Zugriffstoken generieren. Diese Token können verwendet werden, um API-Anforderungen im Namen von Benutzer\\*innen zu senden.\n\nSie müssen den geheimen Clientschlüssel Ihrer App und alle generierten Token nach Möglichkeit sicher speichern. Der Speichermechanismus und die damit zusammenhängende Sicherheit hängen mit deiner Integrationsarchitektur und der Plattform zusammen, auf der die App ausgeführt wird. Im Allgemeinen solltest du einen Mechanismus verwenden, der für die Speicherung vertraulicher Daten auf der von dir verwendeten Plattform konzipiert ist.\n\n### Client-Geheimnisse\n\nGeheime Clientschlüssel sind erforderlich, um Zugriffstoken für Ihre App zu generieren, es sei denn, Ihre App verwendet den Gerätefluss. Weitere Informationen finden Sie unter [Autorisieren von OAuth-Apps](/de/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow).\n\nWenn Es sich bei Ihrer App um einen vertraulichen Client handelt, was bedeutet, dass der geheime Clientschlüssel sicher bleibt, sollten Sie den geheimen Clientschlüssel in einem Schlüsseltresor speichern, z. B. [Azure Key Vault](https://azure.microsoft.com/products/key-vault) oder als verschlüsselte Umgebungsvariable oder geheimer Schlüssel auf Ihrem Server.\n\nWenn deine App ein öffentlicher Client ist (eine native App, die auf dem Gerät des Benutzenden, dem CLI-Hilfsprogramm oder der Single-Page-Webanwendung ausgeführt wird), kannst du dein Geheimnis nicht schützen. In diesem Fall müssen Sie das Client-Geheimnis im Anwendungscode übermitteln und den Authentifizierungsablauf besser mit PKCE schützen. Du solltest mit großer Vorsicht vorgehen, wenn du planst, den Zugriff auf deine eigenen Dienste basierend auf von deiner App generierten Token zu schützen, weil öffentliche Clients sehr einfach zu spoofen sind: Prinzipiell können alle Benutzenden die Client-ID deiner App nutzen, um sich anzumelden.\n\n#### Den Geräteflow nicht grundlos aktivieren\n\nEs ist besser, den Autorisierungscode mit PKCE anstelle des Geräteflows zu verwenden, wenn du Bedenken bezüglich der Verwendung des Clientgeheimnisses in einem öffentlichen Client hast. Der Geräteflow erfordert keinerlei Umleitungs-URIs. Das bedeutet, dass ein Angreifer mithilfe des Geräteflows aus der Ferne die Identität deiner App bei einem Phishingangriff annehmen kann. Aus diesem Grund sollten Sie den Gerätefluss nur dann für Ihre Anwendung aktivieren, wenn Sie die App in einer eingeschränkten Umgebung (CLIs, IoT-Geräte oder kopflose Systeme) verwenden.\n\n### Zugriffstoken\n\nWenn es sich bei deiner App um eine Website oder Web-App handelt, solltest du die Token in deinem Back-End verschlüsseln und sicherstellen, dass rund um die Systeme, die auf die Token zugreifen können, Sicherheit herrscht. Du solltest erwägen, Aktualisierungstoken an anderer Stelle zu speichern als aktive Zugriffstoken.\n\nWenn deine App ein nativer Client oder eine clientseitige App ist oder auf einem Benutzergerät ausgeführt wird (im Gegensatz zur Ausführung auf deinen Servern), kannst du Token möglicherweise nicht so gut schützen wie eine App, die auf deinen Servern ausgeführt wird. Du solltest Token mit dem Mechanismus speichern, der für die Plattform deiner App empfohlen wird. Denk aber daran, dass der Speichermechanismus möglicherweise nicht vollständig sicher ist.\n\n## Verwenden des geeigneten Tokentyps\n\nOAuth apps kann Zugriffstoken generieren, um authentifizierte API-Anforderungen zu erstellen. Ihre App sollte zur Authentifizierung niemals ein personal access token- oder GitHub-Kennwort verwenden.\n\n## Verwenden Sie zeitlich begrenzte Zugriffstoken\n\nUm die regelmäßige Tokenrotation zu erzwingen und die Auswirkungen eines kompromittierten Tokens zu verringern, sollten Sie Ihre OAuth app Konfiguration so konfigurieren, dass Zugriffstoken verwendet werden, die ablaufen. Wenn Ihre App Zugriffstoken verwendet, die ablaufen, erhalten Sie ein Aktualisierungstoken, wenn Sie ein Zugriffstoken generieren. Das Zugriffstoken läuft nach acht Stunden ab, und das Aktualisierungstoken läuft nach sechs Monaten ab. Sie können das Aktualisierungstoken verwenden, um ein neues Zugriffstoken und ein neues Aktualisierungstoken zu generieren. Weitere Informationen finden Sie unter [Autorisieren von OAuth-Apps](/de/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#expiring-access-tokens).\n\nUm die Unterstützung für ablaufende Token zu testen und schrittweise einzuführen, können Sie festlegen, dass Sie bei einer Anmeldung ablaufende Token erhalten, indem Sie zusätzlich zu Ihren anderen Scopes den Scope `offline_access` anfordern. Wenn Ihre App sowohl GitHub Enterprise Server als auch GitHub.com unterstützt, rechnen Sie damit, dass der Gültigkeitsbereich `offline_access` keine Wirkung hat, da die Instanz GitHub Enterprise Server möglicherweise noch keine ablaufenden Token unterstützt. Überprüfen Sie, ob das `expires_in` Feld in der Tokenantwort vorhanden ist, um zu verstehen, ob Ihre App ein ablaufendes Token erhalten hat.\n\n## Aktivieren Sie den Wildcard-Abgleich für Rückruf-URLs nur, wenn nötig.\n\n> \\[!WARNING]\n> Durch aktivieren des Wildcardabgleichs kann Ihre App Sicherheitsrisiken offenlegen, da ein Angreifer Autorisierungscodes an eine unterdomäne oder ein Unterverzeichnis der Rückruf-URL senden kann. Aktivieren Sie nur den Wildcardabgleich, wenn Sie ihn unbedingt benötigen, und Sie sind ganz sicher, dass Sie alle möglichen Unterdomänen und Pfade der Rückruf-URL steuern. Weitere Informationen finden Sie unter [OAuth 2.0 Security Best Current Practice](https://www.rfc-editor.org/info/rfc9700/#section-4.1.1-11).\n\n## Erstellen eines Plans für die Behandlung von Sicherheitsverletzungen\n\nDu solltest einen Plan vorbereiten, damit du jegliche Sicherheitsverletzungen schnellstmöglich korrigieren kannst.\n\nFür den Fall, dass der geheime Clientschlüssel deiner App kompromittiert wird, musst du ein neues Geheimnis generieren, deine App aktualisieren, sodass sie das neue Geheimnis verwendet, und das alte Geheimnis löschen.\n\nWenn Zugriffstoken kompromittiert werden, sollten Sie diese Token sofort widerrufen. Weitere Informationen finden Sie unter [REST-API-Endpunkte für OAuth-Autorisierungen](/de/rest/apps/oauth-applications#delete-an-app-token).\n\n## Regelmäßige Überprüfungen auf Sicherheitsrisiken\n\nDu solltest regelmäßige Sicherheitsrisikoüberprüfungen für deine App durchführen. Beispielsweise kannst du die Codeüberprüfung und die Geheimnisüberprüfung für das Repository einrichten, das den Code deiner App hostet. Weitere Informationen findest du unter [Code-Überprüfung](/de/code-security/concepts/code-scanning/code-scanning) und [Geheimnisüberprüfung](/de/code-security/concepts/secret-security/secret-scanning).\n\n## Auswählen einer geeigneten Umgebung\n\nWenn deine App auf einem Server ausgeführt wird, vergewissere dich, dass deine Serverumgebung sicher ist und das für deine App erwartete Datenverkehrsvolumen verarbeiten kann.\n\n## Sichere Nutzung von Diensten\n\nWenn deine App Dienste von Drittanbietern verwendet, müssen sie auf sichere Art und Weise genutzt werden:\n\n* Alle von deiner App genutzten Dienste sollten über einen eindeutigen Anmeldenamen und ein eindeutiges Kennwort verfügen.\n* Apps sollten keine Dienstkonten wie E-Mail- oder Datenbankdienste freigeben, um deinen SaaS-Dienst zu verwalten.\n* Nur Mitarbeiter\\*innen mit Verwaltungsaufgaben sollten Administratorzugriff auf die Infrastruktur haben, in der deine App gehostet wird.\n\n## Hinzufügen von Protokollierung und Überwachung\n\nFüge ggf. Protokollierungs- und Überwachungsfunktionen für dein App hinzu. Ein Sicherheitsprotokoll kann Folgendes enthalten:\n\n* Authentisierungs- und Autorisierungsereignisse\n* Änderungen der Dienstkonfiguration\n* Lesen und Schreiben von Objekten\n* Benutzer- und Gruppenberechtigungsänderungen\n* Erhöhung der Rolle zum Administrator\n\nDeine Protokolle sollten für jedes Ereignis konsistente Zeitstempelung verwenden und die Benutzer\\*innen, IP-Adressen oder Hostnamen für alle protokollierten Ereignisse aufzeichnen.\n\n## Aktivieren der Datenlöschung\n\nWenn deine App für andere Benutzer*innen verfügbar ist, solltest du Benutzer*innen die Möglichkeit geben, ihre Daten zu löschen. Benutzer*innen sollten nicht per E-Mail oder telefonisch eine*n Suppormitarbeiter\\*in kontaktieren müssen, um ihre Daten zu löschen.\n\n## Weiterführende Lektüre\n\n* [Bewährte Methoden für Sicherheit für Apps auf GitHub Marketplace](/de/apps/github-marketplace/creating-apps-for-github-marketplace/security-best-practices-for-apps-on-github-marketplace)\n* [Bewährte Methoden für Kundenfreundlichkeit für Apps](/de/apps/github-marketplace/creating-apps-for-github-marketplace/customer-experience-best-practices-for-apps)"}