Auf dieser Seite finden Sie einige gängige Anwendungsfälle für die Authentifizierung und Autorisierung mit Links zu weiteren Informationen zum Implementieren der einzelnen Anwendungsfälle.
Eine Übersicht über die Authentifizierung bei Google finden Sie unter Authentifizierung bei Google.
Bei Google APIs authentifizieren
Google APIs erfordern bei jeder Anfrage ein gültiges Zugriffstoken oder einen API-Schlüssel. Wie Sie diese erforderlichen Anmeldedaten angeben, hängt davon ab, wo Ihr Code ausgeführt wird und welche Arten von Anmeldedaten die API akzeptiert.
Clientbibliotheken und Standardanmeldedaten für Anwendungen verwenden
Zum Verwenden von Google APIs wird empfohlen, eine Clientbibliothek und Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) zu verwenden. Application Default Credentials (ADC) ist eine Strategie, die von den Google-Authentifizierungsbibliotheken verwendet wird, um Anmeldedaten automatisch basierend auf der Anwendungsumgebung zu finden. Die Authentifizierungsbibliotheken stellen diese Anmeldedaten für Cloud-Clientbibliotheken und Google API-Clientbibliotheken zur Verfügung. Wenn Sie ADC verwenden, kann Ihr Code in einer Entwicklungs- oder Produktionsumgebung ausgeführt werden, ohne dass sich die Authentifizierung Ihrer Anwendung bei Google Cloud-Diensten und APIs ändert.
Wie Sie ADC einrichten, hängt davon ab, wo Ihr Code ausgeführt wird. ADC unterstützt sowohl die Authentifizierung als Dienstkonto als auch die Authentifizierung als Nutzer.
Von Google Kubernetes Engine (GKE) authentifizieren
Mit Workload Identity können Sie in GKE ausgeführte Arbeitslasten für den sicheren Zugriff auf Google APIs aktivieren. Workload Identity ermöglicht einem GKE-Dienstkonto in Ihrem GKE-Cluster, als IAM-Dienstkonto (Identity and Access Management) zu fungieren.
Authentifizieren Sie sich in Cloud Run for Anthos
Sie authentifizieren Ihre Cloud Run for Anthos-Dienste mit Workload Identity, mit dem Sie auf Google APIs zugreifen können.
Eine API verwenden, die API-Schlüssel akzeptiert
API-Schlüssel verknüpfen eine API-Anfrage mit einem Google Cloud-Projekt für Abrechnungs- und Kontingentzwecke. Wenn eine API API-Schlüssel unterstützt, kann anstelle der Tokens ein API-Schlüssel mit der API-Anfrage bereitgestellt werden. Informationen dazu, ob eine API API-Schlüssel unterstützt, finden Sie in der Dokumentation zu Ihrer API.
Selbstsignierte JSON Web Tokens (JWTs) verwenden
Einige Google APIs unterstützen selbst signierte JSON Web Tokens (JWTs) anstelle von Zugriffstoken. Mit einem selbst signierten JWT können Sie keine Netzwerkanfrage an den Autorisierungsserver von Google senden. Für dieses Vorgehen müssen Sie ein eigenes signiertes JWT erstellen. Weitere Informationen zu Tokens finden Sie unter Tokentypen.
Authentifizierungsbibliotheken und -pakete verwenden
Wenn ADC und die von den Cloud-Clientbibliotheken oder Google API-Clientbibliotheken bereitgestellte OAuth-Implementierung in Ihrer Umgebung nicht verfügbar sind, können Sie die Authentifizierungsbibliotheken und -pakete verwenden.
Die folgenden Authentifizierungsbibliotheken und -pakete sind verfügbar:
Sie können den OAuth 2.0-Flow auch mit den OAuth 2.0-Endpunkten von Google implementieren. Für diesen Ansatz benötigen Sie ein detaillierteres Verständnis der Funktionsweise von OAuth 2.0 und OpenID Connect. Weitere Informationen finden Sie unter Using OAuth 2.0 for Web Server Applications.
Google Cloud-Dienst-spezifische Anwendungsfälle
Einige Google Cloud-Dienste unterstützen Authentifizierungsabläufe, die für diesen Dienst spezifisch sind.
Mithilfe signierter URLs zeitlich begrenzten Zugriff auf eine Cloud Storage-Ressource gewähren
Signierte URLs bieten zeitlich begrenzten Zugriff auf eine bestimmte Cloud Storage-Ressource.
Bei GKE Enterprise-Clustern authentifizieren
Sie können sich bei GKE Enterprise-Clustern mit Google Cloud-Identitäten oder mithilfe eines externen Identitätsanbieters authentifizieren:
- Authentifizieren Sie sich mit Google Cloud-Identitäten über das Connect-Gateway.
- Authentifizieren Sie sich mit dem Anthos Identity Service bei einem externen Identitätsanbieter, der OIDC oder LDAP unterstützt.
Mit API-Gateway oder Cloud Endpoints bereitgestellte API zur Authentifizierung konfigurieren
API Gateway und Cloud Endpoints unterstützen die Dienst-zu-Dienst-Authentifizierung und die Nutzerauthentifizierung mit Firebase, von Google signierten ID-Tokens, Okta, Auth0 und JWTs.
Weitere Informationen finden Sie in der Produktdokumentation:
- Authentifizierungsmethode für API Gateway auswählen
- Authentifizierungsmethode für Cloud Endpoints auswählen
Authentifizierung für Anwendungen, die in Cloud Run oder Cloud Functions gehostet werden
Für Anwendungen, die in Cloud Run und Cloud Functions gehostet werden, sind zur Authentifizierung OpenID Connect-Tokens (OIDC) oder ID-Tokens erforderlich.
Weitere Informationen finden Sie in der Produktdokumentation für die unten aufgeführten Hostingdienste. Informationen zu anderen Möglichkeiten zum Abrufen eines ID-Tokens finden Sie unter ID-Token abrufen. Weitere Informationen zu ID-Tokens, einschließlich der Validierung von ID-Tokens, finden Sie unter ID-Tokens.
Cloud Run
Je nachdem, wie der Dienst aufgerufen wird, haben Sie verschiedene Möglichkeiten, einen Cloud Run-Dienst einzurichten. Möglicherweise müssen Sie auch sich über einen Cloud Run-Dienst bei anderen Diensten authentifizieren, für die ein OIDC-ID-Token erforderlich ist.
Sie verwenden Identity Platform oder Firebase Authentication, um Nutzer über eine Web- oder mobile App für Ihren Dienst zu authentifizieren. Sie können auch Identity-Aware Proxy (IAP) zum Authentifizieren interner Nutzer verwenden.
Cloud Functions
Wenn Sie eine Funktion aufrufen, müssen Sie den Aufruf authentifizieren. Sie können Nutzeranmeldedaten oder ein OIDC-ID-Token verwenden.
Anwendungsnutzer authentifizieren
Abhängig von der übrigen Anwendungsumgebung haben Sie verschiedene Optionen zur Authentifizierung der Endnutzer Ihrer Anwendung. Verwenden Sie die folgenden Beschreibungen, um die beste Option für Ihre Anwendung zu verstehen.
| Authentifizierungsdienst | Beschreibung |
|---|---|
| Google Identity Services |
Google Identity Services umfasst die Anmeldung mit Google, die Schaltfläche "Nutzeranmeldung" von Google sowie Identity Services APIs und SDK. Google Identity Services basiert auf den OAuth 2.0- und OpenID Connect-Protokollen (OIDC). Wenn Sie eine mobile Anwendung erstellen und Nutzer mit Gmail- und Google Workspace-Konten authentifizieren möchten, können Sie „Über Google anmelden” verwenden. „Über Google anmelden” unterstützt auch die Verwendung von Google-Konten mit einem vorhandenen Anmeldesystem. Weitere Informationen "Sign In With Google" bietet die Anmeldung für Gmail- und Google Workspace-Konten und die Unterstützung für Einmalpasswörter (One-Time Passwords, OTP). „Über Google anmelden” ist auf reine Google-Konten oder auf Google-Konten in einem vorhandenen Anmeldesystem für mobile Anwendungen ausgerichtet. "Über Google anmelden" ist für iOS, Android und Webanwendungen verfügbar. |
| Firebase Authentication |
Firebase Authentication bietet Authentifizierungsdienste und Bibliotheken, um Nutzer für Ihre Anwendung für eine Vielzahl von Nutzerkontotypen zu authentifizieren. Wenn Sie Nutzeranmeldungen von mehreren Plattformen akzeptieren möchten, ist Firebase Authentication möglicherweise eine gute Option. Weitere Informationen Firebase Authentication bietet Authentifizierungsfunktionen für viele Nutzerkontentypen. Firebase Authentication unterstützt die Passwortauthentifizierung und die föderierte Anmeldung bei Google, Facebook, Twitter und anderen Plattformen. Identity Platform und Firebase Authentication basieren beide auf Google Identity-Diensten. Firebase Authentication ist auf Nutzeranwendungen ausgerichtet. Identity Platform ist ideal für Nutzer, die ihr eigener Identitätsanbieter sein möchten oder die die unternehmensfähigen Funktionen von Identity Platform benötigen. Weitere Informationen zu den Unterschieden zwischen diesen Produkten finden Sie unter Unterschiede zwischen Identity Platform und Firebase Authentication. Weitere Informationen finden Sie unter den folgenden Links:
|
| Identity Platform |
Identity Platform ist eine Plattform zur Identitäts- und Zugriffsverwaltung für Kunden (Customer Identity and Access Management, CIAM), mit der Organisationen ihre Anwendungen um IAM-Funktionen für Unternehmen ergänzen können. Wenn Sie eine Anwendung zur Verwendung mit einem Google-Identitätsanbieter wie Google Workspace oder einem eigenen Identitäts- und Zugriffsverwaltungsdienst erstellen, ist Identity Platform eine gute Option. Weitere Informationen Identity Platform bietet einen anpassbaren Drop-in-Identitäts- und Authentifizierungsdienst für die Nutzerregistrierung und -anmeldung. Identity Platform unterstützt verschiedene Authentifizierungsmethoden: SAML, OIDC, E-Mail-Adresse/Passwort, über soziale Netzwerke, Telefon und benutzerdefinierte Optionen. Identity Platform und Firebase Authentication basieren beide auf Google Identity-Diensten. Firebase Authentication ist auf Nutzeranwendungen ausgerichtet. Identity Platform ist ideal für Nutzer, die ihr eigener Identitätsanbieter sein möchten oder die die unternehmensfähigen Funktionen von Identity Platform benötigen. Weitere Informationen zu den Unterschieden zwischen diesen Produkten finden Sie unter Unterschiede zwischen Identity Platform und Firebase Authentication. |
| OAuth 2.0 und OpenID Connect |
Mit OpenID Connect können Sie Authentifizierungstokens mit den meisten Anpassungsoptionen verarbeiten und verwenden. Wenn Sie maximale Kontrolle über Ihre OAuth 2.0-Implementierung haben und mit OAuth 2.0-Abläufen umgehen möchten, sollten Sie diese Option in Betracht ziehen. Weitere Informationen Die OAuth 2.0-Implementierung von Google entspricht der OpenID Connect-Spezifikation und ist OpenID-zertifiziert. OpenID Connect liegt eine Identitätsebene über dem OAuth 2.0-Protokoll. Ihre Anwendung kann OpenID Connect verwenden, um das ID-Token zu validieren und Nutzerprofilinformationen abzurufen. OAuth 2.0 kann zur Implementierung der programmatischen Authentifizierung für eine mit Identity-Aware Proxy (IAP) geschützte Ressource verwendet werden. |
| Identity-Aware Proxy (IAP) |
Mit IAP können Sie den Zugriff auf die Anwendung steuern, bevor Anfragen die Anwendungsressourcen erreichen. Im Gegensatz zu den anderen Authentifizierungsdienste in dieser Tabelle, die in Ihrer Anwendung implementiert sind, führt IAP die Authentifizierung aus, bevor Ihre Anwendung erreicht wird. Weitere Informationen Mit IAP richten Sie eine zentrale Autorisierungsebene für Anwendungen ein und sichern Ihre Anwendung mithilfe von signierten Headern. Auf IAP-geschützte Anwendungen kann nur von Hauptkonten mit der richtigen IAM-Rolle zugegriffen werden. Versucht ein Endnutzer, auf eine mit IAP gesicherte Ressource zuzugreifen, führt IAP Authentifizierungs- und Autorisierungsprüfungen für Sie aus. IAP schützt nicht vor Aktivitäten innerhalb eines Projekts, z. B. einem anderen Dienst innerhalb desselben Projekts. Für Google-Identitäten verwendet IAP ID-Tokens. Weitere Informationen finden Sie unter Programmatische Authentifizierung. Informationen dazu, wie IAP Ihre Anwendungsressourcen sichert, finden Sie in der IAP-Übersicht. Die folgenden sprachspezifischen Anleitungen sind für IAP verfügbar: |
| App Engine Users API | Für Anwendungen, die in der App Engine-Standardumgebung ausgeführt werden, ist die Users API verfügbar. Sie bietet Funktionen zur Nutzerauthentifizierung für einige Sprachen. |
| Zugriff für Endnutzerressourcen autorisieren | Wenn Ihre Anwendung auf Ressourcen zugreift, die Ihrem Endnutzer gehören, müssen Sie die Berechtigung dazu erteilen. Dies wird mitunter als dreibeiniges OAuth oder 3LO bezeichnet, da drei Entitäten beteiligt sind: die Anwendung, der Autorisierungsserver und der Nutzer. |
Authentifizierungs- und Autorisierungsoptionen für Google Cloud und Google Workspace
Google Cloud und Google Workspace bieten verschiedene Optionen zum Einrichten des Zugriffs, zum Verbessern der Kontosicherheit und zum Verwalten der Konten.
Zugriff auf Google Cloud-Ressourcen für externe Arbeitslasten gewähren
Mit der Identitätsföderation von Arbeitslasten können Sie lokalen oder Multi-Cloud-Arbeitslasten Zugriff auf Google Cloud-Ressourcen gewähren. In der Vergangenheit war für diesen Anwendungsfall die Verwendung von Dienstkontoschlüsseln erforderlich. Die Workload Identity-Föderation umgeht jedoch die Wartung und den Sicherheitsaufwand für die Verwendung von Dienstkontoschlüsseln. Die Workload Identity-Föderation unterstützt viele OIDC-kompatible oder SAML 2.0-kompatible Identitätsanbieter. Zu den unterstützten Identitätsanbietern gehören AWS, Azure Active Directory, lokales Active Directory, Okta, GitHub Actions und Kubernetes-Cluster.
Identitätsanbieter einrichten
Sie können Google als Identitätsanbieter mit Cloud Identity oder Google Workspace verwenden. Sie können auch ein Cloud Identity- oder Google Workspace-Konto mit einem externen Identitätsanbieter verbinden. Bei diesem Ansatz wird SAML verwendet, sodass sich Ihre Mitarbeiter mit ihrer vorhandenen Identität und ihren Anmeldedaten bei Google-Dienste anmelden können.
2-Faktor-Authentifizierung einrichten.
Die Anforderung der 2-Faktor-Authentifizierung ist eine Best Practice, um zu verhindern, dass böswillige Nutzer auf ein Konto zugreifen, wenn sie Zugriff auf die Anmeldedaten für dieses Konto erhalten haben. Bei der 2-Faktor-Authentifizierung ist für die Authentifizierung dieses Nutzers eine zweite Information oder Identifizierung durch den Nutzer erforderlich. Google bietet verschiedene Lösungen, die den Standard FIDO (Fast IDentity Online) unterstützen.
Identity Platform unterstützt die 2-Faktor-Authentifizierung für Web-, iOS- und Android-Anwendungen.
Google Identity Services unterstützt die FIDO-Authentifizierung (Fast IDentity Online).
Google unterstützt verschiedene Hardwarelösungen für die 2-Faktor-Authentifizierung, z. B. Titan Keys.
Zertifikatbasierten Zugriff einrichten
Als Teil der BeyondCorp Enterprise-Zero-Trust-Lösung beschränkt der zertifikatbasierte Zugriff den Zugriff auf authentifizierte Nutzer auf einem vertrauenswürdigen Gerät und identifiziert Geräte über ihre X.509-Zertifikate. Der zertifikatbasierte Zugriff wird manchmal auch als gegenseitige Transport Layer Security (mTLS) bezeichnet.
Allgemeine Konto- und Authentifizierungsinformationen
Hilfe beim Zugriff auf ein Google-Konto
Hilfe beim Zugriff auf oder zur Verwaltung eines Google-Kontos finden Sie auf der Supportseite für Google-Konten.
Umgang mit manipulierten Anmeldedaten
Wenn Sie der Meinung sind, dass Ihre Anmeldedaten manipuliert wurden, können Sie oder Ihr Administrator Maßnahmen ergreifen, um die Situation zu verringern. Weitere Informationen finden Sie unter manipulierte Google Cloud-Anmeldedaten verarbeiten.
Hilfe bei Problemen mit Zertifizierungsstellen
Wenn Fehler im Zusammenhang mit einem Problem mit Ihrem Zertifikat oder der Zertifizierungsstelle, einschließlich Ihrer Stamm-CA, auftreten, lesen Sie die FAQ zu Google Trust Services.