🔗 Service-to-Service Auth, Webhooks, and Event-Driven Security

Intro: Internal calls, background events, and third-party callbacks are often treated like plumbing. They should be treated like security boundaries because they carry identity, authority, and replay risk.

What this page includes

service-to-service authentication patterns

identity propagation choices

webhook security basics that actually matter

message-bus and asynchronous workflow controls

Service-to-service authentication

Use one of these patterns deliberately:

mTLS when transport identity matters and service mesh or PKI operations are mature;
signed tokens when application-layer claims and scopes are needed;
gateway-only trust only for very simple topologies and never as the long-term default.

Identity propagation

Propagate the minimum useful identity context:

caller subject;
tenant context;
request correlation ID;
authorization decision or scopes only when downstream services need them.

Do not let downstream services infer identity solely from source IP, service name, or a user-controlled header.

Webhook security baseline

sign payloads;
verify timestamp and replay window;
pin expected source identity or endpoint where practical;
separate secret rotation from functional configuration;
log delivery ID, verification result, and target workflow.

Event-driven patterns

Message buses and asynchronous systems need their own authorization model.

Good defaults:

producer identities scoped per application or service;
topic or queue authorization by action and environment;
schema validation at publish and consume edges;
dead-letter review for security-sensitive consumers.

Anti-patterns

a single broker credential shared by many services;
webhook endpoints that trust only source IP;
consumers that trust event content without validating the actor or tenant context;
downstream services that reconstruct authorization from unauthenticated headers.