Best Practices

Auf dieser Seite finden Sie einige allgemeine Best Practices für die Integration mit OAuth 2.0. Beachten Sie diese Best Practices zusätzlich zu allen spezifischen Anleitungen für Ihren Anwendungstyp und Ihre Entwicklungsplattform. Lesen Sie auch die Hinweise zur Vorbereitung Ihrer App für die Produktionsphase und die OAuth 2.0-Richtlinien von Google.

Sicherer Umgang mit Clientanmeldedaten

Die OAuth-Clientanmeldedaten identifizieren die Identität Ihrer App und sollten sorgfältig behandelt werden. Speichern Sie diese Anmeldedaten nur in einem sicheren Speicher, z. B. mit einem Secret Manager wie Google Cloud Secret Manager. Die Anmeldedaten dürfen nicht fest codiert, in ein Code-Repository eingecheckt oder öffentlich veröffentlicht werden.

Sicherer Umgang mit Nutzer-Tokens

Nutzer-Tokens umfassen sowohl Aktualisierungstokens als auch Zugriffstokens, die von Ihrer Anwendung verwendet werden. Speichern Sie Tokens sicher im Ruhezustand und übertragen Sie sie niemals als Klartext. Verwenden Sie ein sicheres Speichersystem, das für Ihre Plattform geeignet ist, z. B. Keystore unter Android, Keychain Services unter iOS und macOS oder Credential Locker unter Windows.

Widerrufen Sie Tokens, sobald sie nicht mehr benötigt werden, und löschen Sie sie dauerhaft aus Ihren Systemen.

Beachten Sie außerdem die folgenden Best Practices für Ihre Plattform:

  • Bei serverseitigen Anwendungen, in denen Tokens für viele Nutzer gespeichert werden, sollten Sie die Tokens im Ruhezustand verschlüsseln und dafür sorgen, dass Ihr Datenspeicher nicht öffentlich über das Internet zugänglich ist.
  • Für native Desktop-Apps wird dringend empfohlen, das PKCE-Protokoll (Proof Key for Code Exchange) zu verwenden, um Autorisierungscodes abzurufen, die gegen Zugriffstokens eingetauscht werden können.

Widerruf und Ablauf von Aktualisierungstokens verarbeiten

Wenn Ihre App ein Aktualisierungstoken für den Offlinezugriff angefordert hat, müssen Sie auch die Ungültigkeit oder das Ablaufen des Tokens berücksichtigen. Tokens können aus verschiedenen Gründen ungültig werden, z. B. weil sie abgelaufen sind oder der Zugriff Ihrer Apps vom Nutzer oder durch einen automatisierten Prozess widerrufen wurde. In diesem Fall sollten Sie sorgfältig überlegen, wie Ihre Anwendung reagieren soll, z. B. ob der Nutzer bei der nächsten Anmeldung aufgefordert werden soll oder ob seine Daten bereinigt werden sollen. Wenn Sie über den Widerruf von Tokens benachrichtigt werden möchten, binden Sie den Dienst Produktübergreifender Kontoschutz ein.

Inkrementelle Autorisierung verwenden

Verwenden Sie die inkrementelle Autorisierung, um die entsprechenden OAuth-Bereiche anzufordern, wenn die Funktion von Ihrer Anwendung benötigt wird.

Sie sollten nicht beim ersten Authentifizieren des Nutzers Zugriff auf Daten anfordern, es sei denn, dies ist für die Hauptfunktionen Ihrer App unbedingt erforderlich. Fordern Sie stattdessen nur die spezifischen Bereiche an, die für eine Aufgabe benötigt werden, und halten Sie sich dabei an das Prinzip, die kleinstmöglichen, eingeschränktesten Bereiche auszuwählen.

Fordern Sie Bereiche immer im Kontext an, damit Ihre Nutzer verstehen, warum Ihre App Zugriff anfordert und wie die Daten verwendet werden.

Ihre Anwendung könnte beispielsweise diesem Modell folgen:

  1. Der Nutzer authentifiziert sich mit Ihrer App.
    1. Es werden keine zusätzlichen Bereiche angefordert. Die App bietet grundlegende Funktionen, mit denen der Nutzer Funktionen nutzen kann, für die keine zusätzlichen Daten oder kein zusätzlicher Zugriff erforderlich sind.
  2. Der Nutzer wählt eine Funktion aus, für die Zugriff auf zusätzliche Daten erforderlich ist.
    1. Ihre Anwendung stellt eine Autorisierungsanfrage für diesen spezifischen OAuth-Bereich, der für diese Funktion erforderlich ist. Wenn für diese Funktion mehrere Bereiche erforderlich sind, beachten Sie die Best Practices unten.
    2. Wenn der Nutzer die Anfrage ablehnt, deaktiviert die App die Funktion und gibt dem Nutzer zusätzlichen Kontext, um den Zugriff noch einmal anzufordern.

Einwilligung für mehrere Bereiche verarbeiten

Wenn Sie mehrere Bereiche gleichzeitig anfordern, gewähren Nutzer möglicherweise nicht alle von Ihnen angeforderten OAuth-Bereiche. Ihre App sollte die Ablehnung von Bereichen durch Deaktivieren der entsprechenden Funktionen verarbeiten.

Wenn für die grundlegenden Funktionen Ihrer App mehrere Bereiche erforderlich sind, müssen Sie dies dem Nutzer erklären, bevor Sie ihn um die Einwilligung bitten.

Sie dürfen den Nutzer erst dann wieder auffordern, wenn er eindeutig die Absicht geäußert hat, die spezifische Funktion zu verwenden, für die der Bereich erforderlich ist. Ihre App sollte dem Nutzer relevanten Kontext und eine Begründung liefern, bevor OAuth-Bereiche angefordert werden.

Sie sollten die Anzahl der Berechtigungen, die Ihre App gleichzeitig anfordert, minimieren. Verwenden Sie stattdessen die inkrementelle Autorisierung, um Bereichsanfragen im Kontext von Funktionen zu stellen.

Sichere Browser verwenden

Im Web dürfen OAuth 2.0-Autorisierungsanfragen nur von vollwertigen Webbrowsern gestellt werden. Achten Sie auf anderen Plattformen darauf, den richtigen OAuth-Clienttyp auszuwählen und OAuth entsprechend Ihrer Plattform zu integrieren. Leiten Sie die Anfrage nicht über eingebettete Browserumgebungen weiter, einschließlich WebViews auf mobilen Plattformen wie WebView unter Android oder WKWebView unter iOS. Verwenden Sie stattdessen native OAuth-Bibliotheken oder Google Log-in für Ihre Plattform.

Manuelles Erstellen und Konfigurieren von OAuth-Clients

Um Missbrauch zu verhindern, können OAuth-Clients nicht programmatisch erstellt oder geändert werden. Sie müssen die Nutzungsbedingungen in der Google Developers Console explizit bestätigen, Ihren OAuth-Client konfigurieren und die OAuth-Überprüfung vorbereiten.

Für automatisierte Workflows sollten Sie stattdessen Dienstkonten verwenden.

Nicht verwendete OAuth-Clients entfernen

Prüfen Sie Ihre OAuth 2.0-Clients regelmäßig und löschen Sie proaktiv alle, die für Ihre Anwendung nicht mehr erforderlich sind oder veraltet sind. Wenn Sie ungenutzte Clients konfiguriert lassen, stellt dies ein potenzielles Sicherheitsrisiko dar, da der Client missbraucht werden kann, wenn Ihre Clientanmeldedaten jemals kompromittiert werden.

Um das Risiko durch nicht verwendete Clients weiter zu minimieren, werden OAuth 2.0-Clients, die seit sechs Monaten inaktiv sind, automatisch gelöscht.

Es wird empfohlen, nicht auf die automatische Löschung zu warten, sondern ungenutzte Clients proaktiv zu entfernen. Dadurch wird die Angriffsfläche Ihrer Anwendung minimiert und für eine gute Sicherheit gesorgt.