Best Practices

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Clientanmeldedaten sicher verarbeiten

Die OAuth-Clientanmeldedaten identifizieren die Identität Ihrer App und sollten mit Bedacht behandelt werden. Speichern Sie diese Anmeldedaten nur in einem sicheren Speicher, z. B. mit einem Secret Manager wie Google Cloud Secret Manager. Hardcodieren Sie die Anmeldedaten nicht, fügen Sie sie keinem Code-Repository hinzu und veröffentlichen Sie sie nicht öffentlich.

Nutzertokens sicher handhaben

Nutzertokens umfassen sowohl Aktualisierungs- als auch Zugriffstokens, die von Ihrer Anwendung verwendet werden. Speichern Sie Tokens sicher in inaktivem Zustand und übertragen Sie sie niemals im Klartext. Verwenden Sie ein sicheres Speichersystem, das für Ihre Plattform geeignet ist, z. B. den Keystore unter Android, Schlüsselbunddienste unter iOS und macOS oder das Anmeldedaten-Verwahrungssystem 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:

• Verschlüsseln Sie bei serverseitigen Anwendungen, die Tokens für viele Nutzer speichern, die ruhenden Tokens und achten Sie darauf, dass Ihr Datenspeicher nicht öffentlich im Internet zugänglich ist.
• Bei nativen Desktop-Apps wird dringend empfohlen, das PKCE-Protokoll (Proof Key for Code Exchange) zu verwenden, um Autorisierungscodes zu erhalten, 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 den Ablauf des Tokens verarbeiten. Tokens können aus verschiedenen Gründen ungültig werden. So kann es beispielsweise sein, dass sie abgelaufen sind oder der Zugriff Ihrer Apps vom Nutzer oder durch einen automatisierten Prozess widerrufen wurde. Überlegen Sie in diesem Fall sorgfältig, wie Ihre Anwendung reagieren sollte, z. B. ob Sie den Nutzer bei der nächsten Anmeldung auffordern oder seine Daten bereinigen sollten. Wenn Sie über den Widerruf eines Tokens benachrichtigt werden möchten, integrieren Sie den Dienst Produktübergreifender Kontoschutz.

Inkrementelle Autorisierung verwenden

Verwenden Sie die inkrementelle Autorisierung, um die entsprechenden OAuth-Bereiche anzufordern, wenn die Funktion für Ihre Anwendung erforderlich ist.

Sie sollten keinen Zugriff auf Daten anfordern, wenn sich der Nutzer zum ersten Mal authentifiziert, es sei denn, dies ist für die Hauptfunktionen Ihrer App unerlässlich. Fordern Sie stattdessen nur die spezifischen Bereiche an, die für eine Aufgabe erforderlich sind, und folgen Sie dem Prinzip, die kleinsten und am wenigsten eingeschränkten Bereiche auszuwählen.

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

Ihre Anwendung könnte beispielsweise diesem Modell folgen:

1. Der Nutzer authentifiziert sich in Ihrer App.
   1. Es werden keine zusätzlichen Bereiche angefordert. Die App bietet grundlegende Funktionen, mit denen Nutzer Funktionen ausprobieren und verwenden können, für die keine zusätzlichen Daten oder Zugriffe erforderlich sind.
2. Der Nutzer wählt eine Funktion aus, für die Zugriff auf zusätzliche Daten erforderlich ist.
   1. Ihre Anwendung sendet eine Autorisierungsanfrage für diesen 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 Gültigkeitsbereiche verarbeiten

Wenn Sie mehrere Bereiche gleichzeitig anfordern, gewähren Nutzer möglicherweise nicht alle von Ihnen angeforderten OAuth-Bereiche. Ihre App sollte den Ausschluss von Bereichen verarbeiten, indem sie die entsprechenden Funktionen deaktiviert.

Wenn die Hauptfunktionen Ihrer App mehrere Bereiche erfordern, erläutern Sie dies dem Nutzer, bevor Sie um seine Einwilligung bitten.

Sie dürfen den Nutzer erst dann wieder um die Einwilligung bitten, wenn er eindeutig seine Absicht erklärt hat, die Funktion zu verwenden, für die der Umfang erforderlich ist. Ihre App sollte dem Nutzer einen relevanten Kontext und eine Begründung liefern, bevor OAuth-Bereiche angefordert werden.

Sie sollten die Anzahl der Bereiche, die Ihre App gleichzeitig anfordert, minimieren. Verwenden Sie stattdessen die inkrementelle Autorisierung, um Bereiche im Kontext von Funktionen anzufordern.

Sichere Browser verwenden

Im Web dürfen OAuth 2.0-Autorisierungsanfragen nur über voll funktionsfähige Webbrowser gestellt werden. Wählen Sie auf anderen Plattformen den richtigen OAuth-Clienttyp aus und integrieren Sie OAuth entsprechend Ihrer Plattform. Die Anfrage darf nicht über eingebettete Browserumgebungen weitergeleitet werden, einschließlich WebViews auf mobilen Plattformen wie WebView auf Android oder WKWebView auf 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 in der Google Developers Console die Nutzungsbedingungen ausdrücklich akzeptieren, Ihren OAuth-Client konfigurieren und sich auf die OAuth-Bestätigung 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, besteht ein potenzielles Sicherheitsrisiko, da der Client missbraucht werden kann, wenn Ihre Clientanmeldedaten kompromittiert werden.

Um die Risiken durch nicht verwendete Clients weiter zu minimieren, werden OAuth 2.0-Clients, die sechs Monate lang inaktiv waren, automatisch gelöscht.

Wir empfehlen, nicht auf das automatische Löschen zu warten, sondern nicht verwendete Clients proaktiv zu entfernen. Dadurch wird die Angriffsfläche Ihrer Anwendung minimiert und eine gute Sicherheitshygiene gewährleistet.