OAuth-Clients freigeben

Auf dieser Seite wird beschrieben, wie Sie einen OAuth-Client für eine andere Anwendung in Ihrer Organisation freigeben.

Übersicht

Wenn Sie OAuth-Clients für mehrere Projekte freigeben, müssen Sie keinen neuen OAuth-Client für jede Anwendung in Ihrer Organisation manuell erstellen. Nachdem Sie einen OAuth-Client manuell erstellt haben, können Sie ihn programmatisch mehreren Anwendungen zuweisen.

Die OAuth-Clientfreigabe wird auch verwendet, um einen Standard-OAuth-Client für Agents freizugeben, die Identity-Aware Proxy (IAP) aktivieren, aber nicht auf die Seite "Anmeldedaten" zugreifen sollen.

Beachten Sie, dass mobile Anwendungen sich nicht bei OAuth-Clients aus einem anderen Projekt authentifizieren können.

Vorbereitung

Folgen Sie einer dieser Anleitungen, um IAP für eine Anwendung zu aktivieren und einen OAuth-Client zu erstellen:

Beachten Sie, dass die Clientfreigabe mit App Engine derzeit nicht unterstützt wird.

Compute Engine-Anwendungen einen freigegebenen Client zuweisen

  1. Rufen Sie die Seite Instanzgruppen auf, um zu prüfen, ob sich Ihre Instanzen in einer Instanzgruppe befinden.
  2. Definieren Sie Back-End-Dienste.
  3. Richten Sie das Load-Balancing ein.
  4. Führen Sie mit dem gcloud-Befehlszeilentool den Befehl gcloud auth login aus:
  5. Folgen Sie der URL, die angezeigt wird, um sich anzumelden.
  6. Kopieren Sie nach der Anmeldung den angezeigten Bestätigungscode und fügen Sie ihn in die Befehlszeile ein.
  7. Führen Sie den Befehl gcloud config set project PROJECT_ID für das Projekt aus, für das Sie IAP aktivieren möchten.
  8. Verwenden Sie die ID und das Secret Ihres freigegebenen Clients von der Seite "Anmeldedaten" und führen Sie den folgenden Befehl aus, um IAP zu aktivieren:

    gcloud compute backend-services update BACKEND_SERVICE_NAME  \
       --global --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET
    

GKE-Anwendungen einen freigegebenen Client zuweisen

Konfigurieren Sie die BackendConfig-Datei Ihrer Anwendung, statt für den folgenden Befehl die ID und das Secret Ihres freigegebenen Clients zu verwenden:

kubectl create secret generic my-secret --from-literal=client_id=CLIENT_ID \
    --from-literal=client_secret=CLIENT_SECRET

Risiken

Es ist zwar bequem, einen Client für mehrere Anwendungen freizugeben, aber es birgt auch Risiken. In diesem Abschnitt wird beschrieben, welche potenziellen Risiken bei der gemeinsamen Nutzung von Clients bestehen und wie sie reduziert werden können.

Single Point Of Failure

Wenn Sie einen OAuth-Client für viele Anwendungen verwenden, wird ein Single Point Of Failure erstellt. Wird ein Client fälschlicherweise gelöscht oder geändert, hat dies Auswirkungen auf jede Anwendung, die diesen Client verwendet.

Nutzen Sie die Clientfreigabe nur bei einem entsprechenden wichtigen Anwendungsfall, um dieses Risiko zu verringern.

Schwachstellen bei Clientschlüsseln

Damit Sie einen Client freigeben können, müssen Sie Ihren Clientschlüssel für andere Personen und Skripts freigeben. Dadurch sind Ihre Clientschlüssel einem größeren Risiko ausgesetzt, in falsche Hände zu gelangen. IAP kann nicht unterscheiden, ob Tokens von Ihrer Anwendung oder aus einem gehackten Clientschlüssel erstellt wurden.

Der Zugriff auf Ihre IAP-Ressourcen kann mit Cloud-Audit-Logging überwacht werden. Wenn Sie befürchten, dass Ihr Clientschlüssel gehackt wurde, setzen Sie ihn auf der Seite "Anmeldedaten" zurück.

Schützen Sie den Clientschlüssel wie ein Passwort, um dieses Risiko zu verringern. Beschränken Sie die Freigabe und speichern Sie ihn niemals als Klartext.

Imitierung der Identität autorisierter Nutzer

Wenn Ihr Clientschlüssel in falsche Hände geraten ist, kann eine schädliche Anwendung das Cookie des IAP-Authentifizierungsbrowsers in seiner Domain so einstellen, dass es die Identität eines berechtigten Nutzers vortäuscht. Mit diesem Cookie authentifiziert IAP dann den Nutzer, dessen Identität imitiert wurde, für alle Anwendungen, die den gehackten Clientschlüssel gemeinsam nutzen.

Um dieses Risiko zu verringern, sollten Sie die gemeinsame Nutzung von Clients durch Ressourcen, die auch gemeinsame autorisierte Nutzer haben, vermeiden. Legen Sie Berechtigungen pro Ressource fest. Damit gewährleisten Sie, dass IAP den Zugriff auch dann nicht autorisiert, wenn ein imitierter Nutzer authentifiziert wurde.

Diebstahl von Nutzeridentitäten

Wenn Ihr Clientschlüssel gehackt wurde, kann eine schädliche Anwendung mit Ihrer Client-ID die Identitäten der Nutzer Ihrer Anwendung auslesen. Dies erfolgt, wenn Nutzer die schädliche Anwendung aufrufen.

Wenn ein Nutzer zum ersten Mal auf eine durch IAP gesicherte Anwendung zugreift, wird er aufgefordert, seine Identität für die Anwendung freizugeben. So haben Nutzer die Kontrolle über ihre personenbezogenen Daten. Wenn ein Nutzer der Freigabe seiner Identität zustimmt, speichert das Google-Anmeldesystem diese Zustimmung. IAP fordert dann den Nutzer bei nachfolgenden Anfragen von Client-IDs im selben Projekt nicht mehr auf.

Jeder Nutzer, der seine Identität für Ihre Anwendung freigibt und die schädliche Anwendung aufruft, gibt ohne seine Zustimmung sofort seine Identität an diese weiter.