Neben der Authentifizierung von Nutzern müssen Sie möglicherweise anderen Diensten gestatten, mit Ihrer API zu interagieren. Für die sichere Kommunikation zwischen Diensten benötigen Sie einen anderen Ansatz als für Clientanwendungen, die Nutzern eine webbasierte Anmeldeaufforderung zum Senden ihrer Anmeldedaten bereitstellen können. Auf dieser Seite wird die Methode gezeigt, die wir zum Implementieren der zwischendienstlichen Authentifizierung empfehlen, begleitet von Beispielcode.
Übersicht
Zur Identifizierung eines Dienstes, der Anfragen an die 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.
So implementieren Sie die Authentifizierung zwischen Diensten in der API und im aufrufenden Dienst:
- Erstellen Sie ein Dienstkonto und einen Schlüssel für den aufrufenden Dienst.
- Konfigurieren Sie die Authentifizierung im OpenAPI-Dokument für Ihren Cloud Endpoints-Dienst.
Ergänzen Sie den Code des aufrufenden Dienstes so, dass:
- ein JWT erstellt und mit dem privaten Schlüssel des Dienstkontos signiert wird und
- das signierte JWT in einer Anfrage an die API gesendet wird.
Der ESP überprüft, ob die Anforderungen im JWT mit der Konfiguration im OpenAPI-Dokument übereinstimmen, bevor er die Anfrage an die API weiterleitet. Der ESP prüft nicht, ob Sie dem Dienstkonto Cloud Identity-Berechtigungen erteilt haben.
Vorbereitung
Folgende Voraussetzungen sollten erfüllt sein:
Dienstkonto mit einem Schlüssel erstellen
Sie benötigen ein Dienstkonto mit einer privaten Schlüsseldatei, die der aufrufende Dienst zum Signieren des JWT verwendet. Wenn mehrere Dienste Anfragen an Ihre API senden, können Sie ein einziges Dienstkonto für alle aufrufenden Dienste erstellen. Falls Sie zwischen den Diensten unterscheiden müssen, weil diese beispielsweise unterschiedliche Berechtigungen haben, können Sie pro aufrufendem Dienst ein Dienstkonto und einen Schlüssel erstellen.
In diesem Abschnitt wird gezeigt, wie Sie mit der Google Cloud Console und dem gcloud
-Befehlszeilentool das Dienstkonto und die Datei mit dem privaten Schlüssel erstellen und dem Dienstkonto die Rolle Ersteller von Dienstkonto-Tokens zuweisen. Wie Sie diese Schritte mithilfe einer API ausführen, erfahren Sie unter Dienstkonten erstellen und verwalten.
So erstellen Sie ein Dienstkonto und eine Schlüsseldatei:
Google Cloud Console
Erstellen Sie ein Dienstkonto:
Wechseln Sie in der Google Cloud Console zur Seite Dienstkonto erstellen.
Wählen Sie das Projekt aus, das Sie verwenden möchten.
Geben Sie im Feld Dienstkontoname einen Namen ein.
Optional: Geben Sie im Feld Dienstkontobeschreibung eine Beschreibung ein.
Klicken Sie auf Erstellen.
Klicken Sie auf das Feld Rolle auswählen. Wählen Sie unter Alle Rollen Dienstkonto > Ersteller von Dienstkonto-Tokens aus.
Klicken Sie auf Fertig.
Schließen Sie das Browserfenster nicht. Sie verwenden es in der nächsten Aufgabe.
Erstellen Sie einen Dienstkontoschlüssel:
- Klicken Sie in der Google Cloud Console auf die E-Mail-Adresse des von Ihnen erstellten Dienstkontos.
- Klicken Sie auf Schlüssel.
- Klicken Sie auf Schlüssel hinzufügen > Neuen Schlüssel erstellen.
- Klicken Sie auf Erstellen. Eine JSON-Datei mit dem privaten Schlüssel des Dienstkontos wird auf Ihren Computer heruntergeladen.
- Klicken Sie auf Schließen.
gcloud
Sie können die folgenden Befehle mit der Google Cloud CLI auf Ihrem lokalen Computer oder in Cloud Shell ausführen.
Legen Sie das Standardkonto für
gcloud
fest. Wenn Sie mehrere Konten haben, müssen Sie das Konto auswählen, das sich im zu verwendenden Google Cloud-Projekt befindet:gcloud auth login
Rufen Sie die Projekt-IDs für Ihre Google Cloud-Projekte ab.
gcloud projects list
Legen Sie das Standardprojekt fest. Ersetzen Sie
PROJECT_ID
durch die Google Cloud-Projekt-ID, die Sie verwenden möchten.gcloud config set project PROJECT_ID
Dienstkonto erstellen Ersetzen Sie
SA_NAME
undSA_DISPLAY_NAME
durch den zu verwendenden Namen bzw. Anzeigenamen:gcloud iam service-accounts create SA_NAME \ --display-name "SA_DISPLAY_NAME"
Rufen Sie die E-Mail-Adresse des gerade erstellten Dienstkontos ab:
gcloud iam service-accounts list
Fügen Sie die Rolle Ersteller von Dienstkonto-Tokens hinzu. Ersetzen Sie
SA_EMAIL_ADDRESS
durch die E-Mail-Adresse des Dienstkontos.gcloud projects add-iam-policy-binding PROJECT_ID \ --member serviceAccount:SA_EMAIL_ADDRESS \ --role roles/iam.serviceAccountTokenCreator
Erstellen Sie im aktuellen Arbeitsverzeichnis eine Schlüsseldatei für das Dienstkonto. Ersetzen Sie dabei
FILE_NAME
durch den Namen, den Sie für die Schlüsseldatei verwenden möchten. Mit dem Befehlgcloud
wird standardmäßig eine JSON-Datei erstellt.gcloud iam service-accounts keys create FILE_NAME.json \ --iam-account SA_EMAIL_ADDRESS
Weitere Informationen zu den vorherigen Befehlen finden Sie in der Referenz zu gcloud
.
Informationen zum Schutz des privaten Schlüssels finden Sie unter Best Practices für die Verwaltung von Anmeldedaten.
API für die Authentifizierung konfigurieren
Das OpenAPI-Dokument muss ein Objekt für Sicherheitsanforderungen und ein Objekt für Sicherheitsdefinitionen enthalten, damit ESP die Anforderungen im signierten JWT validieren kann.
Fügen Sie das Dienstkonto als Aussteller in das OpenAPI-Dokument ein:
securityDefinitions: DEFINITION_NAME: authorizationUrl: "" flow: "implicit" type: "oauth2" x-google-issuer: "SA_EMAIL_ADDRESS" x-google-jwks_uri: "https://www.googleapis.com/robot/v1/metadata/x509/SA_EMAIL_ADDRESS"
- Ersetzen Sie
DEFINITION_NAME
durch einen String, der diese Sicherheitsdefinition bezeichnet. Sie könnten dazu den Namen des Dienstkontos verwenden oder einen Namen, der den anrufenden Dienst identifiziert. - Ersetzen Sie
SA_EMAIL_ADDRESS
durch die E-Mail-Adresse des Dienstkontos. - Sie können mehrere Sicherheitsdefinitionen im OpenAPI-Dokument angeben, allerdings muss jede Definition einen anderen
x-google-issuer
haben. Nachdem Sie getrennte Dienstkonten für jeden aufrufenden Dienst erstellt haben, legen Sie für jeden Dienst eine Sicherheitsdefinition fest. Beispiel:
securityDefinitions: service-1: authorizationUrl: "" flow: "implicit" type: "oauth2" x-google-issuer: "service-1@example-project-12345.iam.gserviceaccount.com" x-google-jwks_uri: "https://www.googleapis.com/robot/v1/metadata/x509/service-1@example-project-12345.iam.gserviceaccount.com" service-2: authorizationUrl: "" flow: "implicit" type: "oauth2" x-google-issuer: "service-2@example-project-12345.iam.gserviceaccount.com" x-google-jwks_uri: "https://www.googleapis.com/robot/v1/metadata/x509/service-2@example-project-12345.iam.gserviceaccount.com"
- Ersetzen Sie
Fügen Sie optional
x-google-audiences
in den AbschnittsecurityDefinitions
ein. Wenn Siex-google-audiences
nicht hinzufügen, setzt ESP voraus, dass die Anforderung"aud"
(Zielgruppe) im JWT das Formathttps://SERVICE_NAME
hat. Dabei ist SERVICE_NAME der Name des Endpoints-Dienstes, den Sie im Feldhost
des OpenAPI-Dokuments angegeben haben, sofern nicht das Flag--disable_jwt_audience_service_name_check
verwendet wird. Wenn das Flag verwendet wird undx-google-audiences
nicht angegeben ist, wird das JWT-Feldaud
nicht geprüft.Fügen Sie optional
x-google-jwt-locations
in den AbschnittsecurityDefinitions
ein. Sie können diesen Wert verwenden, um einen benutzerdefinierten JWT-Speicherort zu definieren. Die Standard-JWT-Standorte sind der HeaderAuthorization
(mit dem Präfix "Bearer"), der HeaderX-Goog-Iap-Jwt-Assertion
oder der Abfrageparameteraccess_token
. Hinweis:- Wenn Sie
x-google-jwt-locations
angeben, ignoriert Endpoints alle Standardspeicherorte. x-google-jwt-locations
wird nur von ESPv2 unterstützt.
- Wenn Sie
Fügen Sie den Abschnitt
security
entweder auf der obersten Ebene der Datei (nicht eingerückt oder verschachtelt) ein, um ihn auf die gesamte API anzuwenden, oder auf der Methodenebene, um ihn auf eine bestimmte Methode zu beschränken. Wenn Sie den Abschnittsecurity
sowohl auf der API-Ebene als auch auf der Methodenebene verwenden, werden die Einstellungen auf der API-Ebene durch die Einstellungen auf der Methodenebene überschrieben.security: - DEFINITION_NAME: []
- Ersetzen Sie
DEFINITION_NAME
durch den Namen, den Sie im AbschnittsecurityDefinitions
verwendet haben. Wenn Sie mehrere Definitionen im Abschnitt
securityDefinitions
haben, fügen Sie sie im Abschnittsecurity
hinzu. Beispiel:security: - service-1: [] - service-2: []
- Ersetzen Sie
Stellen Sie das aktualisierte OpenAPI-Dokument bereit. Ersetzen Sie dabei
OPENAPI_DOC
durch den Namen des OpenAPI-Dokuments.gcloud endpoints services deploy OPENAPI_DOC
Bevor der ESP eine Anfrage an die API weiterleitet, überprüft er:
- Die Signatur des JWT mithilfe des öffentlichen Schlüssels, der sich im URI befindet und im Feld
x-google-jwks_uri
des OpenAPI-Dokuments angegeben wurde. - Ob die Anforderung
"iss"
(issuer) im JWT mit dem im Feldx-google-issuer
angegebenen Wert übereinstimmt. - Ob die Anforderung
"aud"
(audience) im JWT den Namen des Endpoints-Dienstes enthält oder mit einem der Werte übereinstimmt, die Sie im Feldx-google-audiences
angegeben haben. - Ob das Token abgelaufen ist. Das erfolgt mithilfe der Anforderung
"exp"
(expiration time).
Weitere Informationen zu x-google-issuer
, x-google-jwks_uri
, x-google-audiences
und x-google-jwt-locations
finden Sie unter OpenAPI-Erweiterungen.
Authentifizierte Anfrage an eine Endpoints API senden
Bei einer authentifizierten Anfrage sendet der aufrufende Dienst ein JWT, das vom Dienstkonto signiert wurde, das Sie im OpenAPI-Dokument angegeben haben. Der anrufende Dienst muss folgende Schritte ausführen:
- Ein JWT erstellen und mit dem privaten Schlüssel des Dienstkontos signieren.
- Das signierte JWT in einer Anfrage an die API senden.
Der folgende Beispielcode veranschaulicht diesen Prozess für ausgewählte Sprachen. Um eine authentifizierte Anfrage in anderen Sprachen zu stellen, jwt.io.
- Fügen Sie im aufrufenden Dienst die folgende Funktion hinzu und übergeben Sie ihr folgende Parameter:
Java saKeyfile
: Der vollständige Pfad zum privaten Schlüssel des Dienstkontos.-
saEmail
: Die E-Mail-Adresse des Dienstkontos. -
audience
: Wenn Sie das Feldx-google-audiences
in das OpenAPI-Dokument eingefügt haben, legen Sieaudience
auf einen der Werte fest, die Sie fürx-google-audiences
angegeben haben. Setzen Sie andernfallsaudience
aufhttps://SERVICE_NAME
, wobeiSERVICE_NAME
der Name des Endpoints-Dienstes ist. expiryLength
: Die Ablaufzeit des JWT in Sekunden.
Python -
sa_keyfile
: Der vollständige Pfad zum privaten Schlüssel des Dienstkontos. -
sa_email
: Die E-Mail-Adresse des Dienstkontos. -
audience
: Wenn Sie das Feldx-google-audiences
in das OpenAPI-Dokument eingefügt haben, legen Sieaudience
auf einen der Werte fest, die Sie fürx-google-audiences
angegeben haben. Setzen Sie andernfallsaudience
aufhttps://SERVICE_NAME
, wobeiSERVICE_NAME
der Name des Endpoints-Dienstes ist. expiry_length
: Die Ablaufzeit des JWT in Sekunden.
Go saKeyfile
: Der vollständige Pfad zum privaten Schlüssel des Dienstkontos.-
saEmail
: Die E-Mail-Adresse des Dienstkontos. -
audience
: Wenn Sie das Feldx-google-audiences
in das OpenAPI-Dokument eingefügt haben, legen Sieaudience
auf einen der Werte fest, die Sie fürx-google-audiences
angegeben haben. Setzen Sie andernfallsaudience
aufhttps://SERVICE_NAME
, wobeiSERVICE_NAME
der Name des Endpoints-Dienstes ist. expiryLength
: Die Ablaufzeit des JWT in Sekunden.
Die Funktion erstellt ein JWT, signiert es mithilfe der privaten Schlüsseldatei und gibt das signierte JWT zurück.
Java Python Go - Fügen Sie im aufrufenden Dienst die folgende Funktion hinzu, um das signierte JWT im Header
Authorization: Bearer
der Anfrage an die API zu senden:Java Python Go
Wenn Sie eine Anfrage mit einem JWT senden, empfehlen wir aus Sicherheitsgründen, das Authentifizierungstoken in den Header Authorization: Bearer
einzufügen. Beispiel:
curl --request POST \ --header "Authorization: Bearer ${TOKEN}" \ "${ENDPOINTS_HOST}/echo"
Dabei sind ENDPOINTS_HOST
und TOKEN
Umgebungsvariablen, die den Hostnamen der API bzw. das Authentifizierungstoken enthalten.
Authentifizierte Ergebnisse in Ihrer API empfangen
Der ESP leitet in der Regel alle empfangenen Header weiter. Der ESP überschreibt aber möglicherweise den ursprünglichen Authorization
-Header, wenn die Back-End-Adresse in der OpenAPI-Spezifikation durch x-google-backend
oder in der gRPC-Dienstkonfiguration mit BackendRule
angegeben wird.
Der ESP sendet das Authentifizierungsergebnis in X-Endpoint-API-UserInfo
an die Back-End-API. Wir empfehlen die Verwendung dieses Headers anstelle des ursprünglichen Authorization
-Headers. Dieser Header ist ein String, in den base64url
ein JSON-Objekt codiert. Das JSON-Objektformat unterscheidet sich zwischen ESPv2 und ESP.
Bei ESPv2 ist das JSON-Objekt genau die ursprüngliche JWT-Nutzlast. Für ESP verwendet das JSON-Objekt unterschiedliche Feldnamen und platziert die ursprüngliche JWT-Nutzlast im Feld claims
.
Weitere Informationen zum Format finden Sie unter JWTs im Back-End-Dienst verarbeiten.