Wenn ein Push-Abo eine Authentifizierung verwendet, signiert der Pub/Sub-Dienst ein JWT und sendet es im Autorisierungsheader der Push-Anfrage. Das JWT enthält Ansprüche und eine Signatur.
Abonnenten können das JWT validieren und Folgendes prüfen:
- Die Ansprüche sind korrekt.
- Der Pub/Sub-Dienst hat die Ansprüche signiert.
Wenn Abonnenten eine Firewall verwenden, können sie keine Push-Anfragen empfangen. Um Push-Anfragen zu erhalten, müssen Sie die Firewall deaktivieren und das JWT prüfen.
Hinweise
- Weitere Informationen zu Abos
- Machen Sie sich mit der Funktionsweise von Push-Abos vertraut.
- Erstellen Sie ein Push-Abo.
JWT-Format
Das JWT ist ein OpenIDConnect-JWT, das aus einem Header, einem Anforderungssatz und einer Signatur besteht. Der Pub/Sub-Dienst codiert das JWT als Base64-String mit Punkttrennzeichen.
Der folgende Autorisierungsheader enthält beispielsweise ein codiertes JWT:
"Authorization" : "Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjdkNjgwZDhjNzBkNDRlOTQ3MTMzY2JkNDk5ZWJjMWE2MWMzZDVh YmMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJodHRwczovL2V4YW1wbGUuY29tIiwiYXpwIjoiMTEzNzc0M jY0NDYzMDM4MzIxOTY0IiwiZW1haWwiOiJnYWUtZ2NwQGFwcHNwb3QuZ3NlcnZpY2VhY2NvdW50LmNvb SIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJleHAiOjE1NTAxODU5MzUsImlhdCI6MTU1MDE4MjMzNSwia XNzIjoiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tIiwic3ViIjoiMTEzNzc0MjY0NDYzMDM4MzIxO TY0In0.QVjyqpmadTyDZmlX2u3jWd1kJ68YkdwsRZDo-QxSPbxjug4ucLBwAs2QePrcgZ6hhkvdc4UHY 4YF3fz9g7XHULNVIzX5xh02qXEH8dK6PgGndIWcZQzjSYfgO-q-R2oo2hNM5HBBsQN4ARtGK_acG-NGG WM3CQfahbEjZPAJe_B8M7HfIu_G5jOLZCw2EUcGo8BvEwGcLWB2WqEgRM0-xt5-UPzoa3-FpSPG7DHk7 z9zRUeq6eB__ldb-2o4RciJmjVwHgnYqn3VvlX9oVKEgXpNFhKuYA-mWh5o7BCwhujSMmFoBOh6mbIXF cyf5UiVqKjpqEbqPGo_AvKvIQ9VTQ"
Der Header und der Anforderungssatz sind JSON-Strings. Nach der Decodierung nehmen sie die folgende Form an:
{"alg":"RS256","kid":"7d680d8c70d44e947133cbd499ebc1a61c3d5abc","typ":"JWT"} { "aud":"https://example.com", "azp":"113774264463038321964", "email":"gae-gcp@appspot.gserviceaccount.com", "sub":"113774264463038321964", "email_verified":true, "exp":1550185935, "iat":1550182335, "iss":"https://accounts.google.com" }
Die an Anfragen angehängten Tokens an Push-Endpunkte können bis zu einer Stunde alt sein.
Pub/Sub für die Push-Authentifizierung konfigurieren
Das folgende Beispiel zeigt, wie Sie das Dienstkonto für die Push-Authentifizierung auf ein Dienstkonto Ihrer Wahl festlegen und dem Dienst-Agent service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
die Rolle iam.serviceAccountTokenCreator
zuweisen.
Console
Rufen Sie die Seite Pub/Sub-Abos auf.
Klicken Sie auf Abo erstellen.
Geben Sie im Feld Abo-ID einen Namen ein.
Wählen Sie ein Thema aus.
Wählen Sie als Zustellungstyp die Option Push aus.
Geben Sie eine Endpunkt-URL ein.
Klicken Sie das Kästchen Authentifizierung aktivieren an.
Wählen Sie ein Dienstkonto aus.
Achten Sie darauf, dass der Dienst-Agent
service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
im IAM-Dashboard Ihres Projekts die Rolleiam.serviceAccountTokenCreator
hat. Wenn dem Dienstkonto die Rolle nicht zugewiesen wurde, klicken Sie im IAM-Dashboard auf Erteilen.Optional: Geben Sie eine Zielgruppe ein.
Klicken Sie auf Erstellen.
gcloud
# Configure the push subscription gcloud pubsub subscriptions (create|update|modify-push-config) ${SUBSCRIPTION} \ --topic=${TOPIC} \ --push-endpoint=${PUSH_ENDPOINT_URI} \ --push-auth-service-account=${SERVICE_ACCOUNT_EMAIL} \ --push-auth-token-audience=${OPTIONAL_AUDIENCE_OVERRIDE} # Your service agent # `service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com` needs to have the # `iam.serviceAccountTokenCreator` role. PUBSUB_SERVICE_ACCOUNT="service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PUBSUB_SERVICE_ACCOUNT}"\ --role='roles/iam.serviceAccountTokenCreator'
Wenn Sie die Authentifizierung für ein Push-Abo aktivieren, kann der Fehler permission denied
oder not authorized
auftreten.
Erteilen Sie dem Hauptkonto, das die Erstellung oder Aktualisierung des Abos initiiert, die Berechtigung iam.serviceAccounts.actAs
für das Dienstkonto, um dieses Problem zu beheben. Weitere Informationen finden Sie unter Authentifizierung in "Push-Abos erstellen".
Wenn Sie ein authentifiziertes Push-Abo mit einer App Engine-Anwendung verwenden, die mit Identity-Aware Proxy gesichert ist, müssen Sie die IAP-Client-ID als Zielgruppe für das Push-Authentifizierungstoken angeben.
Informationen zum Aktivieren von IAP in Ihrer App Engine-Anwendung finden Sie unter IAP aktivieren.
Die IAP-Client-ID finden Sie auf der Seite Anmeldedaten der IAP-App-Engine-app
-Client-ID.
Anträge
Mit dem JWT kann sichergestellt werden, dass die Anforderungen (einschließlich der email
- und aud
-Anforderungen) von Google unterzeichnet werden. Weitere Informationen dazu, wie die OAuth 2.0 APIs von Google sowohl für die Authentifizierung als auch für die Autorisierung verwendet werden können, finden Sie unter OpenID Connect.
Es gibt zwei Mechanismen, mit denen Sie diese Anforderungen nutzbar machen. Zuerst muss der Nutzer oder das Dienstkonto, der den CreateSubscription-, UpdateSubscription- oder ModifyPushConfig-Aufruf durchführt, eine Rolle mit der Berechtigung iam.serviceAccounts.actAs
für das Push-Auth-Dienstkonto haben. Ein Beispiel für eine solche Rolle ist die Rolle roles/iam.serviceAccountUser
.
Zweitens wird der Zugriff auf die zum Signieren der Tokens verwendeten Zertifikate streng kontrolliert. Zum Erstellen des Tokens muss Pub/Sub einen internen Google-Dienst mit einer separaten Dienstkontoidentität für die Signatur aufrufen. Dies ist der Dienst-Agent service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
.
Dieses signierende Dienstkonto muss die Berechtigung iam.serviceAccounts.getOpenIdToken
oder die Rolle Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator
) für das Dienstkonto für die Push-Authentifizierung (oder für eine Ancestor-Ressource, z. B. das Projekt, des Push-Authentifizierungsdienstkontos) haben.
Token validieren
Die Validierung von Tokens, die von Pub/Sub an den Push-Endpunkt gesendet werden, umfasst folgende Aufgaben:
- Die Integrität des Tokens mithilfe der Signaturvalidierung prüfen.
- Achten Sie darauf, dass die Anforderungen E-Mail und Zielgruppe im Token mit den Werten übereinstimmen, die in der Konfiguration des Push-Abo festgelegt wurden.
Das folgende Beispiel zeigt, wie eine Push-Anfrage an eine App Engine-Anwendung authentifiziert wird, die nicht mit Identity-Aware Proxy gesichert ist. Wenn Ihre App Engine-Anwendung mit IAP gesichert ist, lautet der HTTP-Anfrageheader, der das IAP-JWT enthält, x-goog-iap-jwt-assertion
und muss entsprechend validiert werden.
Protokoll
Anfrage:
GET https://oauth2.googleapis.com/tokeninfo?id_token={BEARER_TOKEN}
Antwort:
200 OK
{ "alg": "RS256", "aud": "example.com", "azp": "104176025330667568672", "email": "{SERVICE_ACCOUNT_NAME}@{YOUR_PROJECT_NAME}.iam.gserviceaccount.com", "email_verified": "true", "exp": "1555463097", "iat": "1555459497", "iss": "https://accounts.google.com", "kid": "3782d3f0bc89008d9d2c01730f765cfb19d3b70e", "sub": "104176025330667568672", "typ": "JWT" }
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C# API.
Einfach loslegen (Go)
Java
Node.js
Python
Ruby
Informationen zur Umgebungsvariable PUBSUB_VERIFICATION_TOKEN
, die in den obigen Codebeispielen verwendet wird, finden Sie unter Pub/Sub-Nachrichten schreiben und beantworten.
Weitere Beispiele zur Validierung des Inhaber-JWT finden Sie im Leitfaden zu Google Log-in für Websites. Eine umfassendere Übersicht über OpenID-Tokens finden Sie im Handbuch zu OpenID Connect. Dort finden Sie auch eine Liste von Clientbibliotheken, mit denen JWTs validiert werden können.
Authentifizierung von anderen Google Cloud-Diensten
Cloud Run, App Engine und Cloud Functions authentifizieren HTTP-Aufrufe von Pub/Sub, indem von Pub/Sub generierte Tokens geprüft werden. Die einzige Konfiguration, die Sie benötigen, besteht darin, dem Aufruferkonto die erforderlichen IAM-Rollen zuzuweisen.
In den folgenden Leitfäden und Anleitungen finden Sie verschiedene Anwendungsfälle mit diesen Diensten:
Cloud Run
- Aus Pub/Sub-Push auslösen: Ihr Dienstkonto für die Push-Authentifizierung muss die Rolle
roles/run.invoker
haben und an einen Cloud Run-Dienst gebunden sein, um einen entsprechenden Cloud Run-Dienst aufzurufen. - Pub/Sub mit Cloud Run verwenden
App Engine
Cloud Functions
- HTTP-Trigger: Ihr Dienstkonto für die Push-Authentifizierung muss die Rolle
roles/cloudfunctions.invoker
zum Aufrufen einer Funktion haben, wenn Sie Pub/Sub-Push-Anfragen als HTTP-Trigger für die Funktion verwenden möchten. - Google Cloud Pub/Sub-Trigger: IAM-Rollen und -Berechtigungen werden automatisch konfiguriert, wenn Sie mit Pub/Sub-Triggern eine Funktion aufrufen.