Cloud Endpoints unterstützt mehrere Authentifizierungsmethoden, die sich für unterschiedliche Anwendungen und Anwendungsfälle eignen. Der Extensible Service Proxy (ESP) verwendet die Authentifizierungsmethode, die Sie in der Dienstkonfiguration angegeben haben, um eingehende Anfragen zu prüfen, bevor sie an das API-Back-End weitergeleitet werden. In diesem Dokument erhalten Sie eine Übersicht sowie Beispiele für Anwendungsfälle zu jeder unterstützten Authentifizierungsmethode.
API-Schlüssel
Ein API-Schlüssel ist ein einfacher verschlüsselter String, der ein Google Cloud-Projekt zu Kontingent-, Abrechnungs- und Monitoringzwecken identifiziert. Ein Entwickler generiert in einem Projekt in der Google Cloud Console einen API-Schlüssel und bettet ihn in jeden Aufruf Ihrer API als Abfrageparameter ein.
Wenn Sie für die API in der Dienstkonfiguration das Anfordern von API-Schlüsseln festlegen, verwendet der ESP den API-Schlüssel, um das Google Cloud-Projekt zu suchen, dem dieser zugeordnet ist. Der ESP lehnt Anfragen generell ab, es sei denn, der API-Schlüssel wurde in Ihrem Google Cloud-Projekt oder in anderen Google Cloud-Projekten generiert, in denen die API aktiviert wurde. Weitere Informationen finden Sie unter API-Zugriff mit API-Schlüsseln einschränken.
Im Gegensatz zu Anmeldedaten, die kurzlebige Tokens oder signierte Anfragen verwenden, sind API-Schlüssel Teil der Anfrage. Da sie für Man-in-the-Middle-Angriffe anfällig sind, gelten sie als weniger sicher. Sie können API-Schlüssel zusätzlich zu einer der unten beschriebenen Authentifizierungsmethoden verwenden. Daher sollten Sie aus Sicherheitsgründen nicht ausschließlich API-Schlüssel verwenden, wenn API-Aufrufe Nutzerdaten enthalten.
Anwendungsfall
Wenn Sie Endpoints-Features wie quotas verwenden möchten, muss in jeder Anfrage ein API-Schlüssel übergeben werden, damit Endpoints das Google Cloud-Projekt identifizieren kann, dem die Clientanwendung zugeordnet ist.
Weitere Informationen zu API-Schlüsseln finden Sie unter API-Schlüssel effizient nutzen.
Authentifizierung mit Firebase
Die Firebase Authentication stellt Backend-Dienste, SDKs und Bibliotheken für die Nutzerauthentifizierung in mobilen Apps oder Webanwendungen bereit. Für die Authentifizierung der Nutzer werden verschiedene Anmeldedaten etwa von Google, Facebook, Twitter oder GitHub verwendet.
Nachdem sich der Nutzer angemeldet hat, signiert die Firebase-Clientbibliothek ein JSON Web Token (JWT) mit einem privaten Schlüssel. Der ESP validiert, dass das JWT von Firebase signiert wurde und die Anforderung iss (issuer) im JWT, die Ihre Firebase-Anwendung identifiziert, mit der Einstellung issuer in der Dienstkonfiguration übereinstimmt.
Anwendungsfall
Die Verwendung von Firebase wird empfohlen, wenn die API-Aufrufe Nutzerdaten beinhalten und die API in Abläufen verwendet werden soll, in denen der Nutzer über eine Benutzeroberfläche wie etwa in mobilen Apps oder Webanwendungen verfügt. Weitere Informationen finden Sie im Artikel Nutzer authentifizieren auf dem Tab "Firebase".
Auth0
Mit Auth0 können Apps und APIs ungeachtet des Identitätsanbieters, der Plattform, des Pakets und des Geräts authentifiziert und autorisiert werden.
Auth0 unterstützt zahlreiche Anbieter sowie die SAML-Spezifikation (Security Assertion Markup Language). Die Anwendung bietet Back-End-Dienste, SDKs und Benutzeroberflächen-Bibliotheken für die Authentifizierung von Nutzern in Webanwendungen und mobilen Apps. Auth0 lässt sich außerdem in verschiedene andere Identitätsanbieter einbinden und bietet eine benutzerdefinierte Nutzerkontenverwaltung.
Die von Auth0 bereitgestellte Clientbibliothek generiert und signiert nach der Anmeldung des Nutzers ein JWT. Der ESP validiert, dass das JWT von Auth0 signiert wurde und die Anforderung iss im JWT, die Ihre Auth0-Anwendung identifiziert, mit der Einstellung issuer in der Dienstkonfiguration übereinstimmt.
Anwendungsfall
Auth0 eignet sich gut für Webanwendungen und mobile Apps für Nutzer und Unternehmen. Weitere Informationen finden Sie im Artikel Nutzer authentifizieren auf dem Tab "Auth0".
Mit Google-ID-Token authentifizieren
Bei der Authentifizierung mit einem Google-ID-Token können sich Nutzer durch die Anmeldung über ein Google-Konto authentifizieren. Nach der Authentifizierung haben die Nutzer Zugriff auf alle Google-Dienste. Sie können mit Google-ID-Tokens Google APIs und von Endpoints verwaltete APIs aufrufen. Der ESP validiert das Google-ID-Token mit dem öffentlichen Schlüssel, damit die iss-Anforderung im JWT https://accounts.google.com ist.
Anwendungsfall
Die Authentifizierung mit einem Google-ID-Token ist dann zu empfehlen, wenn alle Nutzer Google-Konten haben. Sie können die Authentifizierung mit einem Google-ID-Token beispielsweise verwenden, wenn Ihre API für Google-Anwendungen wie etwa eine Google Drive-Begleitanwendung genutzt wird. Bei der Authentifizierung mit Google-ID-Tokens können sich die Nutzer durch die Anmeldung über ein Google-Konto authentifizieren. Nach der Authentifizierung haben die Nutzer Zugriff auf alle Google-Dienste. Weitere Informationen finden Sie im Artikel Nutzer authentifizieren auf dem Tab "Google-ID-Token".
Dienstkonten
Zur Identifizierung eines Dienstes, der Anfragen an Ihre API sendet, wird ein Dienstkonto verwendet. Mit dem privaten Schlüssel des Dienstkontos signiert der aufrufende Dienst ein sicheres JSON Web Token (JWT) und sendet es in der Anfrage an die API.
Anwendungsfall
JWTs und Dienstkonten eignen sich gut für Mikrodienste. Weitere Informationen finden Sie unter Authentifizierung mit einem Dienstkonto.
Benutzerdefinierte Authentifizierung
Sie können auch andere Plattformen verwenden, um Nutzer zu authentifizieren, solange diese dem RFC 7519-Standard für JSON Web Tokens entsprechen.
Weitere Informationen finden Sie im Artikel Nutzer authentifizieren auf dem Tab "Benutzerdefiniert".