A webhook URL is not an authentication plan
A museum connects its inventory event topic to a serverless webhook that updates a staging log. An attacker who learns the HTTPS endpoint may send a fabricated event body unless the receiver authenticates who made the request. Google Pub/Sub supports authenticated push subscriptions: Pub/Sub attaches a signed OpenID Connect JSON Web Token in the request’s Authorization header. This creates a way to verify the claimed sender, but it does not validate the inventory data inside the message. Treat transport identity, message schema, idempotency, and editorial approval as four separate controls. The examples here are illustrative; no production endpoint was configured or tested for this article.
Choose a dedicated push identity
Configure a service account solely for the authenticated push subscription rather than borrowing a broad administrator identity. The actor creating or modifying a subscription needs permission to act as that service account, and the Pub/Sub service agent may need serviceAccountTokenCreator as described in Google’s setup documentation. Keep who can change the push configuration distinct from who can publish messages to the topic. A narrow identity makes it easier to audit unexpected requests and rotate access policies. Document the subscription, project, service account, endpoint, and intended audience as one controlled configuration. A valid-looking webhook payload should never bypass that identity check merely because it contains a familiar event type.
Verify JWT signature and claims
At the receiving endpoint, validate the JWT using a trusted verification library and the documented issuer and key material, not by simply base64-decoding it. Check the intended audience, the authorized service account identity, the token’s expiry, and applicable issuer constraints. The aud claim must identify the intended receiver; a token issued for another webhook should fail even if its cryptographic signature is genuine. Establish a fixed, reviewed audience configuration rather than deriving it from untrusted headers. Handle missing tokens and invalid signatures with an explicit rejection that does not mutate inventory data. Log only a safe reason code and an opaque request identifier, not the full token.
Keep authentication separate from event semantics
A valid signed request may still carry a malformed accession identifier, a nonexistent object, or a change that a staff member never approved. Decode the Pub/Sub envelope, validate the message schema, confirm the event type is allowed for this subscription, and check any domain-specific permissions. If the event requests removal of an archival record, route it to a protected review queue rather than applying deletion from a webhook. Signed delivery proves the calling service identity, not truth of content or the sender’s business authority. Scope the endpoint to a small set of actions, such as appending an audit record or signaling that a review is required.
Compare rejection and acceptance cases
Three conceptual examples show why one green authentication check is insufficient. A request with no bearer token must be rejected. A signed token with the wrong audience must also be rejected, even if the message body uses the right museum object identifier. A correctly signed request with matching audience can continue to schema validation and an idempotency check; it is not automatically an approved catalog edit. Draw the distinctions in the operator dashboard and test each independently with non-sensitive sample messages. Do not present authentication as proof that a donated object was received or that the entry is ready for publication.
Plan for redelivery and retries
Pub/Sub push delivery retries requests that do not receive successful acknowledgment, subject to subscription behavior and configuration. An endpoint may update the audit table but fail to return its acknowledgment before the connection ends. When the message is redelivered, a naïve handler might append the same change twice or send two confirmation emails. Store a stable message or application event ID and make the side effect idempotent, including the race between duplicate requests. Acknowledge only after the durable operation completes, and define how to handle permanently invalid messages. Signing and delivery semantics protect different boundaries; implement both.
Use a staging environment with isolated credentials
Reproduce the push flow with a dedicated staging topic and a receiver that has no production catalog write privileges. Simulate missing JWT, expired token, wrong audience, malformed event structure, and duplicate delivery. Confirm that rejected requests produce no mutation and that an authorized delivery is still subject to event review. Observe metrics for unauthorized attempts, delivery failures, and dead-letter volume without recording sensitive message bodies. Be careful when copying live subscription configuration: a staging webhook must not inherit a production service account or a topic containing restricted donor data. Include a manual stop switch for unusual traffic or suspicious event patterns.
Treat firewall rules as an independent design choice
Google’s guide notes that inbound firewall configurations can interfere with push delivery, including permissions errors. Do not respond by disabling every protection and trusting the presence of a JWT alone. Decide how the endpoint is exposed, use HTTPS, verify tokens server-side, and retain network controls compatible with the chosen hosting environment. For an internal-only consumer, a pull subscription may provide a simpler boundary than a public push endpoint. Document why push was chosen and who owns the receiver. A service-to-service token should complement, not replace, careful deployment isolation, input limits, and incident response procedures.
Create useful incident evidence
For support and audits, record the subscription ID, delivery timestamp, authentication verdict, safe event identifier, schema result, deduplication result, and processing outcome. Do not log bearer tokens, full headers, donor contact details, or entire raw payloads by default. A replay investigation should distinguish a fresh authorized delivery from a duplicate after timeout and a forged request that never passed authentication. Operator dashboards must not turn 200 responses into automatic catalog approvals. Establish an escalation path for unusual authentication failures and review whether the identity or audience configuration has changed before restarting stalled delivery.
Release a secure, reviewable workflow
Before production use, have a second reviewer confirm service account scope, token verification rules, endpoint exposure, and retry-safe processing. Test signed delivery with the actual intended audience, but use synthetic museum events. Keep a clear hold state for data that needs curator approval and ensure that a failed authentication check cannot create even a partial catalog change. Revisit the configuration when the endpoint URL, project, or service identity changes. Pub/Sub authenticated push is a valuable sender-authentication control; the integrity and authority of museum records still depend on the application layered behind it.
How We Research
We reviewed these named official references: Google Cloud Pub/Sub authenticated push guide; Google Cloud Pub/Sub push subscriptions guide. We checked the documented feature, relevant configuration fields, and important stated limitations against a hypothetical museum or archive task. We did not run live production APIs, use real patron or loan records, perform a security penetration test, or measure accuracy, latency, search rank, or costs. The accompanying diagrams are explanatory models, not captured application screenshots or measured results. Verify current documentation, account-specific availability, and permissions before implementation; confirm all public-facing decisions with authorized staff and primary evidence.
Frequently Asked Questions
No. HTTPS protects transport; verify the signed OIDC JWT and its claims to authenticate the caller.
No. Validate the event schema, permissible operation, duplicate status, and any necessary staff authorization.
Check the exact audience configured for the subscription and expected by your endpoint; do not accept arbitrary values from incoming requests.
The event can be redelivered. A stable event ID and idempotent operation prevent repeated side effects.
It should not. Keep token material out of ordinary logs and record only safe verification outcomes and request identifiers.