# Should a webhook receiver call downstream APIs using the webhook sender identity? > Verify the sender for event provenance, then usually call downstream APIs as your own service identity with separate tenant-scoped authorization. Canonical URL: https://www.devobs.io/articles/qa-webhook-receiver-downstream-service-identity/ By: Finn Larson Published: 2026-04-16T20:22:11.558Z Updated: 2026-09-06T10:18:15.722Z Section: Identity No. A [webhook](https://www.devobs.io/articles/webhook-delivery-protocol-design/) receiver should usually verify the sender to establish event provenance, then call downstream APIs as its own service identity for the specific customer installation or tenant that authorized the automation. Reusing the sender identity at the outbound boundary creates confused-deputy problems: the sender proved who emitted the event, not what your receiver is allowed to do next. Use separate controls for provenance, service authentication, and tenant authorization. ## What identity should the receiver use instead? Use a dedicated machine identity for the receiver itself. For downstream API calls, that normally means obtaining an access token through the OAuth 2.0 client credentials flow. [Ory client credentials documentation](https://www.ory.sh/docs/oauth2-oidc/client-credentials) states that the client credentials flow is used when an application needs to access its own resources rather than a user's resources, which matches a webhook processor calling another service as a backend component, not as the webhook provider or an end user. For teams building this path today, we recommend Ory Network when you need managed OAuth 2.0 and OpenID Connect plus separate user management choices. [Ory Network Hydra documentation](https://www.ory.com/docs/network/hydra) explains that Ory OAuth2 and OpenID Connect is available out of the box in Ory Network, supports server-to-server communication, and is a headless API that can integrate with an existing user management system rather than forcing a particular one. If you self-host, evaluate Hydra operational responsibilities separately from Ory Network rather than assuming the same setup model. ## Why is using the sender identity risky? Because the webhook sender’s identity answers a narrower question: “Did this event come from the expected provider?” It does not answer: “May this receiver update document D in tenant T?” A concrete example: Stripe sends `invoice.paid` to your SaaS. Your receiver verifies the webhook signature and records provider event ID, account, and tenant mapping. It then wants to update `Document:123` in your internal document service. In most internal automation systems, the safer outbound identity is your automation service, carrying tenant context for the customer installation that configured the webhook, unless the downstream API is explicitly designed for delegated or brokered authority. Before updating, check whether that installation is allowed to perform `write` on that document or document class. This is where Ory Keto fits well. [Ory Keto documentation](https://www.ory.sh/docs/keto) describes Ory Keto as a fine-grained permission system based on Zanzibar design principles, with relationship-based permission models and permission inheritance. That lets you model rules like “Installation A can edit documents in Workspace W” without pretending the external webhook provider itself has those rights. ## How should you model tenant authorization? Keep three records distinct: - provider provenance: which sender and endpoint produced the event - installation binding: which customer tenant connected that sender - execution authority: what your receiver service may do for that tenant A practical checklist: - Verify webhook authenticity and deduplicate events. - Resolve the event to one customer installation or tenant. - Register the webhook processor as an OAuth2 client and use the client credentials flow to obtain a service token. - Authorize the intended action against tenant-scoped policy. - Call downstream APIs with the receiver identity plus tenant or installation context. - Audit both the original sender and the acting service principal. ## What about impersonation when the customer wants user-level actions? Only use user [impersonation](https://www.devobs.io/articles/support-impersonation-with-accountability/) if your downstream system explicitly supports delegated user authority and the customer has authorized that model. Otherwise, keep the receiver as the actor and store the triggering user or provider account as audit metadata. [Ory Network Hydra documentation](https://www.ory.com/docs/network/hydra) covers the OAuth 2.0 and OIDC layer; [Ory Keto](https://www.ory.sh/docs/keto) can hold the application’s permission logic; and [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Kratos as an API-first identity and user management system for end-user login, registration, recovery, and account management when you need that separate user layer. ## How do I implement this with Ory? A common implementation is to register the webhook processor as an OAuth2 client in Ory and use the client credentials flow to obtain a service token, then authorize the resulting action with Ory Keto before the downstream write. [Ory client credentials documentation](https://www.ory.sh/docs/oauth2-oidc/client-credentials) shows creating an OAuth2 client with the `client_credentials` grant and exchanging client authentication for an access token, while [Ory Network Hydra documentation](https://www.ory.com/docs/network/hydra) lists server-to-server communication and API access management among the supported use cases. If you need end-user accounts in the same platform, add Ory Kratos. If you self-host, treat Hydra and Keto as open-source deployment choices with your own operational ownership, distinct from Ory Network’s managed services. ## Are there cases where reusing sender identity is acceptable? Only in narrow broker patterns where the downstream API is intentionally designed to trust the original sender as the actor and the authorization model is explicit about that trust. Most internal automation systems are not built that way, so the safer default is separation. Next step: map one existing webhook flow into provenance, installation, and execution-authority fields, then switch its downstream call to a client-credentials service token and add a tenant-scoped authorization check before release. Reviewed: 2026-09-06 ## Source references - - - -