Best Practices

Clientanmeldedaten sicher verarbeiten

Die OAuth-Clientanmeldedaten identifizieren Ihre 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.

Nutzer-Tokens sicher verarbeiten

Nutzertokens umfassen sowohl Aktualisierungstokens als auch Zugriffstokens, die von Ihrer Anwendung verwendet werden. Speichern Sie Tokens sicher im Ruhezustand und übertragen Sie sie niemals im Nur-Text-Format. 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 endgültig aus Ihren Systemen.

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

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

Tokens mit DPoP auf Absender beschränken

Um Ihre Anwendung vor Tokendiebstahl und Replay-Angriffen zu schützen, sollten Sie Ihre Tokens mit DPoP (Demonstrating Proof-of-Possession) einschränken. Während Standard-Inhabertoken von jeder Partei verwendet werden können, die sie abfängt, sind DPoP-Tokens kryptografisch an ein eindeutiges Schlüsselpaar gebunden, das vom Client generiert und gespeichert wird.

Bei der Verwendung von DPoP legt der Client dem Token-Endpunkt einen Nachweis (ein signiertes JSON Web Token) vor, wenn er Tokens anfordert oder Aktualisierungstokens anfordert. Dieser Nachweis zeigt, dass der Client im Besitz des privaten Schlüssels ist, der dem an das Token gebundenen öffentlichen Schlüssel entspricht. Wenn ein DPoP-gebundenes Aktualisierungstoken geleakt wird, kann es von einem Angreifer ohne diesen privaten Schlüssel nicht wiedergegeben werden.

DPoP bietet zusammen mit PKCE umfassenden Schutz:

• PKCE schützt den Autorisierungscode während des ersten Weiterleitungsablaufs.
• DPoP schützt das langlebige Aktualisierungstoken und verhindert Replay-Angriffe, falls es kompromittiert wird.

Die Einführung von DPoP wird dringend empfohlen, wenn Ihre Anwendung:

• Wird als installierte oder Desktop-Anwendung (oder als Single-Page-Anwendung in Kombination mit einem Backend-for-Frontend-Server) ausgeführt, bei der Aktualisierungstokens möglicherweise anfälliger für Exfiltration sind.
• Zugriff auf hochsensible Daten oder hochwertige APIs, bei denen die Auswirkungen eines Token-Lecks erheblich sind.
• Sie müssen strenge Compliance- oder Sicherheitsstandards erfüllen, die absenderbeschränkte Tokens vorschreiben.

Eine detaillierte Anleitung zum Erstellen von DPoP-Proofs und zum Anfordern von DPoP-gebundenen Tokens finden Sie im DPoP-Einführungsleitfaden.

Parameter „state“ verwenden

Bevor du eine OAuth 2.0-Antwort verarbeitest, solltest du prüfen, ob der von Google empfangene state mit dem in deiner Autorisierungsanfrage gesendeten state übereinstimmt. Der Parameter state sollte ein eindeutiger, nicht erratbarer Wert sein, der von Ihrer Anwendung generiert wird.

Mit dem Parameter state wird sichergestellt, dass die Anfrage vom Nutzer und nicht von einem schädlichen Script stammt. Außerdem wird das Risiko von websiteübergreifenden Anfragen (Cross-Site Request Forgery) verringert.

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 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. 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, binden Sie den Dienst Produktübergreifender Kontoschutz ein.

Inkrementelle Autorisierung verwenden

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

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

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

Ihre Anwendung könnte 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 Zugriffe 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, folgen Sie den Best Practices für mehrere Bereiche.
   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 verwalten

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 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 ihn um seine Einwilligung bitten.

Sie dürfen den Nutzer erst dann wieder auffordern, wenn er eindeutig die Absicht bekundet hat, die spezifische Funktion zu verwenden, 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 und Features anzufordern.

Sichere Browser verwenden

Im Web dürfen OAuth 2.0-Autorisierungsanfragen nur von Webbrowsern mit vollem Funktionsumfang gestellt werden. Wählen Sie auf anderen Plattformen den richtigen OAuth-Clienttyp aus und binden Sie OAuth entsprechend Ihrer Plattform ein. 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 die empfohlenen OAuth-Bibliotheken oder Google Log-in für Ihre Plattform.

Manuelle Erstellung und Konfiguration von OAuth-Clients

Um Missbrauch zu verhindern, können OAuth-Clients nicht programmatisch erstellt oder geändert werden. Sie müssen die Google Cloud Console verwenden, um die Nutzungsbedingungen explizit zu akzeptieren, Ihren OAuth-Client zu konfigurieren und die OAuth-Überprüfung vorzubereiten.

Für automatisierte Workflows sollten Sie stattdessen Dienstkonten verwenden.

Nicht verwendete OAuth-Clients entfernen

Überprüfen Sie Ihre OAuth 2.0-Clients regelmäßig und löschen Sie proaktiv alle Clients, die von Ihrer Anwendung nicht mehr benötigt werden oder veraltet sind. Wenn Sie nicht verwendete Clients konfiguriert lassen, stellt dies ein potenzielles Sicherheitsrisiko dar, da der Client missbraucht werden kann, wenn Ihre Client-Anmeldedaten jemals manipuliert 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.

Es empfiehlt sich, 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.