Authentication Methods in Confluent Platform

By default, Kafka is installed with no authentication. Confluent Platform supports the following authentication mechanisms and protocols for Kafka brokers.

SASL

SASL (Simple Authentication Security Layer) is a framework that provides developers of applications and shared libraries with mechanisms for authentication, data integrity-checking, and encryption.

  • SASL using JAAS

    Kafka uses the Java Authentication and Authorization Service (JAAS) for SASL configuration. You must provide JAAS configurations for all SASL authentication mechanisms. This topic explains how to configure JAAS for SASL.

  • SASL/GSSAPI (Kerberos)

    SASL/GSSAPI uses your Kerberos or Active Directory server for authentication.

  • SASL/OAUTHBEARER

    Only suitable for use in non-production Kafka installations, SASL/OAUTHBEARER enables the use the OAuth 2 Authorization framework in a SASL context to create and validate unsecured JSON web tokens for authentication.

  • SASL/PLAIN

    SASL/PLAIN uses a simple username and password for authentication.

  • SASL/SCRAM

    SASL/SCRAM uses usernames and passwords stored in ZooKeeper. Credentials are created during installation.

  • Delegation Tokens (SASL/SSL)

    Performs authentication based on delegation tokens that use a lightweight authentication mechanism that you can use to complement existing SASL/SSL methods. Delegation tokens are shared secrets between Kafka brokers and clients.

  • LDAP

    Performs client authentication with LDAP (or AD) across all of your Kafka clusters that use SASL/PLAIN.

mTLS

With mTLS (mutual TLS) authentication, both Kafka clients and servers use TLS certificates to verify each other’s identities to ensure that traffic is secure and trusted in both directions.

HTTP Basic Auth

You can use HTTP Basic Authentication to authenticate with the Admin REST APIs using a username and password pair, which are presented to the REST Proxy server using the Authorization HTTP header.

Single Sign-on (SSO) for Confluent Control Center

You can use Single Sign-on (SSO) for Confluent Control Center to offload the management of your Control Center users and authenticate to an OIDC-compliant identity provider (Microsoft Entra ID (Azure Active Directory), Okta, Keycloak, and others). By using SSO, you can manage your users in one place and use the same credentials to provide a seamless experience across Confluent Control Center and Confluent Cloud.