Auf dieser Seite wird gezeigt, wie Sie die Nutzerauthentifizierung in Cloud Endpoints unterstützen.
Zur Authentifizierung eines Nutzers muss eine Clientanwendung ein JSON-Webtoken (JWT) im Autorisierungs-Header der HTTP-Anfrage an Ihre Back-End-API senden. Der Extensible Service Proxy (ESP) validiert das Token für Ihre API, sodass Sie der API keinen Code zur Verarbeitung der Authentifizierung hinzufügen müssen. Sie müssen Ihr OpenAPI-Dokument jedoch so konfigurieren, dass es die ausgewählten Authentifizierungsmethoden unterstützt.
Der ESP prüft ein JSON-Webtoken (JWT) effizient mithilfe der öffentlichen Schlüssel des JWT-Ausstellers. Dabei speichert der ESP die öffentlichen Schlüssel 5 Minuten lang im Cache. Darüber hinaus speichert der ESP validierte JWTs 5 Minuten lang oder bis zum Ablauf des JWT, je nachdem, was zuerst eintritt.
Hinweis
- Fügen Sie Ihrer Client-Anwendung Authentifizierungscode hinzu. Folgen Sie dazu der Dokumentation zur Firebase-Authentifizierung. Firebase unterstützt die Authentifizierung mithilfe von Passwörtern, Telefonnummern und gängigen föderierten Identitätsanbietern wie Google, Facebook und Twitter.
- Wenn Ihre Clientanwendung eine HTTP-Anfrage sendet, muss der Autorisierungs-Header in der Anfrage die folgenden JWT-Anforderungen enthalten:
iss
(issuer)sub
(subject)aud
(audience)iat
(issued at)exp
(expiration time)
OpenAPI-Dokument konfigurieren
Das OpenAPI-Dokument muss ein Objekt für Sicherheitsanforderungen und ein Objekt für Sicherheitsdefinitionen enthalten, damit der ESP die Anforderungen im signierten JWT validieren kann.
So aktivieren Sie die Firebase-Authentifizierung:
Fügen Sie der Sicherheitsdefinition in Ihrem OpenAPI-Dokument Folgendes hinzu:
securityDefinitions: firebase: authorizationUrl: "" flow: "implicit" type: "oauth2" # Replace YOUR-PROJECT-ID with your project ID x-google-issuer: "https://securetoken.google.com/YOUR-PROJECT-ID" x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com" x-google-audiences: "YOUR-PROJECT-ID"
Fügen Sie den Abschnitt "security" entweder für die gesamte API auf API-Ebene oder für eine bestimmte Methode auf Methodenebene hinzu.
security: - firebase: []
Sie können mehrere Sicherheitsdefinitionen im OpenAPI-Dokument angeben, allerdings muss jede Definition einen anderen Aussteller haben. Wenn Sie den Abschnitt "security" 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.
Sie können auch JWT-Standorte anpassen, indem Sie x-google-extensions
hinzufügen. Weitere Informationen finden Sie unter openAPI-Erweiterungen.
Authentifizierter Aufruf an eine Endpoints API
Wenn Sie eine Anfrage mit einem Authentifizierungstoken senden, empfehlen wir aus Sicherheitsgründen, das Token in den Header Authorization:Bearer
einzufügen. Beispiel:
curl -H "Authorization: Bearer ${TOKEN}" "${ENDPOINTS_HOST}/echo"
Hier sind ENDPOINTS_HOST
und TOKEN
Umgebungsvariablen, die den Hostnamen Ihrer API beziehungsweise das Authentifizierungstoken enthalten. Unter Authentifizierte Anfrage an eine Endpoints API senden finden Sie einen Beispielcode, der eine Anfrage mit dem Header Authorization:Bearer
sendet.
Falls Sie den Header beim Senden der Anfrage nicht verwenden können, können Sie das Authentifizierungstoken in einen Abfrageparameter namens access_token
einfügen.
curl "${ENDPOINTS_HOST}/echo?access_token=${TOKEN}"
Authentifizierte Ergebnisse in Ihrer API empfangen
Der ESP leitet in der Regel alle empfangenen Header weiter. Sie überschreibt jedoch
Ursprünglicher Authorization
-Header, wenn die Backend-Adresse durch angegeben wird durch
x-google-backend
in der OpenAPI-Spezifikation oder BackendRule
in der gRPC-Dienstkonfiguration.
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
.
Siehe JWTs im Back-End-Dienst verarbeiten.
finden Sie weitere Informationen zum Format.
Nächste Schritte