Best Practices

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. Codieren Sie die Anmeldedaten nicht fest, übertragen Sie sie nicht in ein Code-Repository und veröffentlichen Sie sie nicht öffentlich.

Sicherer Umgang mit Nutzertokens

Nutzertokens 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 diese Best Practices für Ihre Plattform:

• Bei serverseitigen Anwendungen, die Tokens für viele Nutzer speichern, sollten Sie sie 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 zu erhalten, die gegen Zugriffstokens ausgetauscht werden können.

Umgang mit dem Widerruf und Ablauf von Aktualisierungstokens

Wenn Ihre App ein Aktualisierungs token für den Offlinezugriff angefordert hat, müssen Sie auch die Ungültigmachung oder den Ablauf 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 einem automatisierten Prozess widerrufen wurde. In diesem Fall sollten Sie sorgfältig überlegen, wie Ihre Anwendung reagieren soll, z. B. indem Sie den Nutzer bei der nächsten Anmeldung auffordern oder seine Daten bereinigen. Wenn Sie über den Widerruf von Tokens benachrichtigt werden möchten, integrieren Sie den produktübergreifenden Kontoschutz.

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 erforderlich sind, und wählen Sie dabei nach dem Prinzip die kleinsten und eingeschränktesten Bereiche aus.

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

Ihre Anwendung kann beispielsweise diesem Modell folgen:

1. Der Nutzer authentifiziert sich bei Ihrer App.
   1. Es werden keine zusätzlichen Bereiche angefordert. Die App bietet grundlegende Funktionen, mit denen der Nutzer Funktionen erkunden und verwenden 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 sendet eine Autorisierungsanfrage für diesen spezifischen OAuth-Bereich, der für diese Funktion erforderlich ist. Wenn für diese Funktion mehrere Bereiche erforderlich sind, folgen Sie den 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.

Umgang mit der Einwilligung für mehrere Bereiche

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

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

Sie dürfen den Nutzer erst dann noch einmal auffordern, wenn er eindeutig angegeben hat, dass er die spezifische Funktion verwenden möchte, für die der Bereich erforderlich ist. Ihre App sollte dem Nutzer relevante Informationen und eine Begründung liefern, bevor sie OAuth-Bereiche anfordert.

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 von voll funktionsfähigen Webbrowsern aus 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 einschließlich WebViews auf mobilen Plattformen wie WebView unter Android oder WKWebView unter iOS weiter. 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 bestätigen, Ihren OAuth-Client konfigurieren und sich auf die OAuth-Überprüfung vorbereiten.

Für automatisierte Arbeitsabläufe sollten Sie stattdessen Dienstkonten verwenden.

Nicht verwendete OAuth-Clients entfernen

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

Um die Risiken 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 nicht verwendete Clients proaktiv zu entfernen. Dadurch wird die Angriffsfläche Ihrer Anwendung minimiert und für eine gute Sicherheitshygiene gesorgt.