Support OAuth2 for Confluent Kafka
AnsweredPlease add support for OAuth 2.0 authentication for Fivetran HVR connections to Confluent and Apache Kafka.
Currently, HVR appears to support only username/password authentication, such as API key and secret, or Kerberos for Kafka connectivity. While these options work, they create operational and security challenges in larger enterprise environments where teams may need to manage many API keys and secrets across multiple Kafka clusters, environments, and applications.
OAuth 2.0 has become a standard enterprise authentication pattern because it enables centralized identity management, short-lived tokens, easier credential rotation, improved auditability, and stronger alignment with modern security controls. Supporting OAuth 2.0 would reduce the need to distribute and maintain long-lived API secrets, while allowing customers to integrate HVR with existing identity providers and access governance processes.
Ideally, HVR would support OAuth 2.0/OIDC-based Kafka authentication flows such as SASL/OAUTHBEARER, including configuration for token endpoints, client credentials, scopes or audiences, and other provider-specific settings required by Confluent or Apache Kafka deployments.
Adding this capability would make HVR easier to operate securely at enterprise scale and would help customers meet modern authentication and compliance requirements without relying on large numbers of static credentials.
Business Impact:
This feature would simplify secret management, reduce security risk from long-lived credentials, improve audit and compliance posture, and make HVR a better fit for organizations standardizing on OAuth 2.0-based authentication across their data platforms.
-
Hi Dylan
Thanks for the detailed request. It is a meaningful area for us to examine, and we’ll review it with engineering.
This could improve HVR’s fit in larger enterprise environments, especially around centralized identity and reducing reliance on long-lived secrets. At the same time, support for Kafka OAuth can vary widely by deployment and provider, so we’d want to assess feasibility and scope carefully rather than assume a fully generic solution upfront.
Best regards,
Edwin
Please sign in to leave a comment.
Comments
1 comment