Hi Pulsar community, I'd like to propose PIP-478: Asynchronous v5 client authentication plugin interfaces and TLS material provider plugin interface. It fills in the client authentication design for the new Java client API (the v5 modules introduced by PIP-466), which only sketched a stub and explicitly invited a follow-up proposal. This is that follow-up.
The proposal replaces the v4 "kitchen-sink" AuthenticationDataProvider with a small core Authentication interface plus narrow, opt-in capability interfaces, segregated by transport (Pulsar binary protocol vs HTTP) and by style (single-pass vs multi-round challenge/response). All credential work is asynchronous (CompletableFuture), so a slow token refresh can no longer block the Netty event loop — the client-side counterpart to PIP-97's broker-side async work. It also adds a framework-managed PulsarHttpClient SPI so auth plugins such as OAuth2 and Athenz share the runtime's HTTP/DNS resources instead of spinning up their own clients, and a purpose-driven PulsarTlsMaterialProvider SPI that replaces PIP-337's PulsarSslFactory / PulsarSslConfiguration. Compatibility bridges in both directions keep the v4 surface and existing third-party plugins working unchanged. Broker-side authentication is intentionally out of scope and will be addressed in a sibling PIP with the same design principles. The feature targets Pulsar 5.0. Full proposal: https://github.com/lhotari/pulsar/blob/lh-pip-478-v5-client-async-auth-and-tls-material-provider/pip/pip-478.md PR: https://github.com/apache/pulsar/pull/25890 Looking forward to your feedback! Lari
