Authentication and Authorization for Producers and Consumers

Authentication and authorization in event-driven systems are easy to under-design because the broker looks like shared infrastructure rather than like a public platform boundary. That is a mistake. Producers and consumers are not merely opening connections. They are gaining the right to publish business facts, read potentially sensitive streams, trigger downstream work, and sometimes replay history.

The first control is identity. Every producer and consumer should authenticate as a specific workload or service identity rather than as a shared team credential. The second control is authorization. That identity should be able to publish only to the subjects it owns and consume only the streams it genuinely needs. Event platforms become risky quickly when wildcard access is treated as operational convenience.

    flowchart LR
	    A["Producer identity"] --> B["Publish policy"]
	    C["Consumer identity"] --> D["Consume policy"]
	    B --> E["Broker or stream platform"]
	    D --> E
	    E --> F["Only approved subjects and streams"]

What to notice:

• connection identity and data-plane permission are separate concerns
• publish rights and consume rights should usually be scoped differently
• a broker is an authorization surface, not just a transport surface

Why Shared Credentials Age Badly

Shared credentials often appear early because they are easy. One integration user or shared access key seems to reduce setup time. Over time it creates several problems:

• weak attribution
• painful rotation
• unclear blast radius
• over-broad privilege
• difficulty proving who published or consumed what

An event platform with many teams and shared credentials is hard to govern because one identity may represent several real services and purposes. That makes both incident response and least-privilege enforcement much weaker.

Least Privilege for Publish and Consume

Least privilege in event systems is often more granular than teams expect. A service may need to:

• publish to one stream
• consume from two others
• read schemas from a catalog
• not replay history
• not inspect unrelated subjects

Those rights should be modeled explicitly rather than approximated with “read/write on the broker.”

 1accessPolicy:
 2  principal: payments-service
 3  allowPublish:
 4    - payments.events
 5  allowConsume:
 6    - orders.events
 7  allowSchemaRead:
 8    - payments.events
 9    - orders.events
10  deny:
11    - customer-support.events
12    - replay-admin

This example is intentionally simple, but it shows the right shape: capability follows actual responsibility.

Consumers Are Security Subjects Too

Teams often think mainly about producer authorization because publishing looks active and dangerous. Consumers are just as important. A consumer that can subscribe broadly may read:

• customer PII
• regulated business facts
• operational secrets in event metadata
• cross-tenant information

This is why consume rights need real review. “Read-only” is not harmless in event-driven systems when streams are durable and replayable.

Replay and Administrative Controls

Administrative capabilities deserve separate treatment from everyday publish and consume rights. Replaying history, changing retention, creating new subjects, or inspecting dead-letter streams often has a much larger blast radius than live consume access.

A strong control model usually separates:

• runtime producer identity
• runtime consumer identity
• operator or platform-admin identity
• replay or recovery privileges

Common Mistakes

• using shared credentials because workload identity feels operationally slower
• treating broker access as one broad permission instead of publish, consume, and administrative capabilities
• assuming consume access is low risk because it is “read only”
• granting wildcard publish rights across related domains for convenience
• forgetting that replay rights often deserve stricter controls than ordinary consumption

Design Review Question

A platform team gives every internal service wildcard consume access to all domain topics because “it reduces onboarding friction.” What should you challenge first?

Challenge the assumption that visibility is harmless. Broad consume rights create unnecessary data exposure, increase cross-domain coupling, and make future privacy and tenant isolation controls much harder. The stronger design is scoped access based on explicit service need.

Quiz Time