Best Practices beim Erstellen einer OAuth-App

Verwenden einer GitHub App als Alternative

Verwende nach Möglichkeit eine GitHub App anstelle einer OAuth app. Im Allgemeinen werden GitHub Apps häufiger als OAuth apps verwendet. GitHub Apps verwenden differenzierte Berechtigungen, bieten Benutzer*innen mehr Kontrolle darüber, auf welche Repositorys die App zugreifen kann, und verwenden 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.

Ähnlich wie OAuth apps können GitHub Apps weiterhin OAuth 2.0 nutzen und eine Art von OAuth-Token (ein sogenanntes Benutzerzugriffstoken) generieren und Aktionen im Namen eines Benutzers bzw. einer Benutzerin ausführen. Jedoch können GitHub Apps unabhängig von demder Benutzerin agieren.

Weitere Informationen zu GitHub Apps findest du unter Informationen zum Erstellen von GitHub-Apps.

Weitere Informationen zum Migrieren einer vorhandenen OAuth app zu einer GitHub App findest du unter Migrieren von OAuth-Apps zu GitHub-Apps.

Verwenden von minimalen Bereichen

Deine OAuth app sollte nur die Bereiche anfordern, die die App für die beabsichtigte Funktionalität benötigt. Wenn Token für deine App kompromittiert werden, lässt sich damit der mögliche Schaden begrenzen. Weitere Informationen findest du unter Autorisieren von OAuth-Apps.

Autorisieren Sie gründlich und dauerhaft

Nach 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.

Verwenden Sie den dauerhaften, eindeutigen `id`, um den Benutzer zu speichern.

Wenn 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.

Um 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 finden Sie unter „REST-API-Endpunkte für Benutzer“.

Wenn Sie Verweise auf Repositorys, Organisationen und Unternehmen speichern, verwenden Sie auch ihre id, um sicherzustellen, dass Ihre Links zu ihnen korrekt bleiben.

Verwenden Sie niemals Bezeichner, die sich im Laufe der Zeit ändern können, einschließlich Benutzerhandles, Organisations-Slugs oder E-Mail-Adressen.

Überprüfen des Organisationszugriffs bei jeder neuen Authentifizierung

Wenn du ein Benutzerzugriffstoken verwendest, solltest du nachverfolgen, für welche Organisationen das Token autorisiert ist. 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 kannst den GET /user/installations-REST-API-Endpunkt verwenden, um zu überprüfen, auf welche Organisationen ein Benutzerzugriffstoken Zugriff hat. Wenn der Benutzer nicht berechtigt ist, auf eine Organisation zuzugreifen, sollten Sie seinen Zugriff auf die Daten der Organisation innerhalb Ihrer eigenen Anwendung verhindern, bis er SAML SSO durchführt. Weitere Informationen findest du unter Rest-API-Endpunkte für GitHub App-Installationen.

Speichern von Benutzerdaten mit Organisations- und Unternehmenskontexten

Ü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.

Zum Beispiel:

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.
Der Benutzer zieht einen Haufen Code aus einem Repository in Mona und speichert ihn in Ihrer Anwendung zur Analyse.
Später wechselt der Benutzer Aufträge und wird aus der Mona Organisation entfernt.

Wenn der Benutzer auf Ihre Anwendung zugreift, kann er dann immer noch den Code und die Analysen der Mona Organisation in seinem Benutzerkonto sehen?

Aus 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.

Bestätigen des Zugriffs eines Benutzers auf Ihre App

Auf Ihre OAuth-App kann 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.

Um 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 findest du unter REST-API-Endpunkte für Organisationen.

Notiz: Auch auf eine OAuth app, die von einem verwaltetes Benutzerkonto oder Organisation mit verwalteten Benutzer*innen erstellt wurde, kann von Benutzern außerhalb des Unternehmens zugegriffen werden.

Schützen der Anmeldeinformationen deiner App

Mit einem geheimen Clientschlüssel kann deine App einen Benutzer bzw. eine Benutzerin autorisieren und Benutzerzugriffstoken generieren. Diese Token können verwendet werden, um API-Anforderungen im Namen von Benutzer*innen zu senden.

Du musst den geheimen Clientschlüssel deiner App und alle generierten Token an einem sicheren Ort speichern. Welchen Speichermechanismus du verwendest, richtet sich nach deiner Integrationsarchitektur und der Plattform, 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.

Geheime Clientschlüssel

Wenn es sich bei deiner App um eine Website oder Web-App handelt, solltest du den geheimen Clientschlüssel in einem Schlüsseltresor wie Azure Key Vault oder als verschlüsselte Umgebungsvariable oder geheimen Clientschlüssel auf deinem Server speichern.

Wenn 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 deinen geheimen Clientschlüssel nicht 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, da jede Person auf den geheimen Clientschlüssel zugreifen kann, um ein Token zu generieren.

Benutzerzugriffstoken

Wenn 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.

Wenn 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.

Verwenden des geeigneten Tokentyps

OAuth apps können Benutzerzugriffstoken generieren, um authentifizierte API-Anforderungen zu senden. Deine App sollte niemals ein personal access token oder ein GitHub-Kennwort für die Authentifizierung verwenden.

Erstellen eines Plans für die Behandlung von Sicherheitsverletzungen

Du solltest einen Plan vorbereiten, damit du jegliche Sicherheitsverletzungen schnellstmöglich korrigieren kannst.

Fü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.

Falls Benutzerzugriffstoken kompromittiert werden, solltest du diese Token sofort widerrufen. Weitere Informationen findest du unter REST-API-Endpunkte für OAuth-Autorisierungen.

Regelmäßige Überprüfungen auf Sicherheitsrisiken

Du 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 Informationen zu Codescans und unter Informationen zur Geheimnisüberprüfung.

Auswählen einer geeigneten Umgebung

Wenn 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.

Sichere Nutzung von Diensten

Wenn deine App Dienste von Drittanbietern verwendet, müssen sie auf sichere Art und Weise genutzt werden:

Alle von deiner App genutzten Dienste sollten über einen eindeutigen Anmeldenamen und ein eindeutiges Kennwort verfügen.
Apps sollten keine Dienstkonten wie E-Mail- oder Datenbankdienste freigeben, um deinen SaaS-Dienst zu verwalten.
Nur Mitarbeiter*innen mit Verwaltungsaufgaben sollten Administratorzugriff auf die Infrastruktur haben, in der deine App gehostet wird.

Hinzufügen von Protokollierung und Überwachung

Füge ggf. Protokollierungs- und Überwachungsfunktionen für dein App hinzu. Ein Sicherheitsprotokoll kann Folgendes enthalten:

Authentisierungs- und Autorisierungsereignisse
Änderungen der Dienstkonfiguration
Lesen und Schreiben von Objekten
Benutzer- und Gruppenberechtigungsänderungen
Erhöhung der Rolle zum Administrator

Deine Protokolle sollten für jedes Ereignis konsistente Zeitstempelung verwenden und die Benutzer*innen, IP-Adressen oder Hostnamen für alle protokollierten Ereignisse aufzeichnen.

Aktivieren der Datenlöschung

Wenn deine App für andere Benutzerinnen verfügbar ist, solltest du Benutzerinnen die Möglichkeit geben, ihre Daten zu löschen. Benutzerinnen sollten nicht per E-Mail oder telefonisch einen Suppormitarbeiter*in kontaktieren müssen, um ihre Daten zu löschen.