# Use Multi-Protocol Authentication in Confluent Platform Confluent Platform clusters support multi-protocol authentication, allowing two or more authentication protocols to be configured and used simultaneously for Confluent Platform services in your cluster. Kafka supports SASL/PLAIN, SASL/PLAIN with LDAP server, SASL/OAUTHBEARER (OAuth 2.0), SASL/GSSAPI (Kerberos), SASL/SCRAM, and mutual TLS (mTLS). All other Confluent Platform services support only OAuth 2.0, mutual TLS, and HTTP Basic Authentication. Typically, one authentication protocol is used for a given Confluent Platform service in a deployment. However, there are scenarios where supporting multiple protocols simultaneously can be beneficial. You can use Confluent Platform services to support multiple protocols for authenticating incoming client requests in certain scenarios. With multi-protocol authentication, a Confluent Platform service can be configured to authenticate clients that use OAuth 2.0, mTLS certificates, or HTTP Basic Authentication. You are not constrained to use only one protocol. * **Transitioning from HTTP Basic Authentication to OAuth 2.0**: If an application is migrating from HTTP Basic Authentication to OAuth 2.0, supporting both temporarily allows a smooth transition for clients. Existing clients can continue using HTTP Basic Authentication while new clients adopt OAuth 2.0. * **Supporting diverse clients**: Some legacy clients may only support HTTP Basic Authentication, while newer clients can leverage OAuth 2.0. Supporting both ensures the application is accessible to a wider range of clients. * **Providing options**: Offering a choice between simpler HTTP Basic Authentication for internal or trusted clients and more secure OAuth 2.0 for external clients can be appropriate in some architectures. * **Different internal and external communication**: If a Confluent Platform cluster needs to authenticate with mutual TLS for all internal platform communications (for example, Schema Registry to Confluent Server, Connect to Schema Registry, Confluent Server to Schema Registry, or Connect to Confluent Server) and use OAuth 2.0 to authenticate client applications to CP services, you can configure use multi-protocol authentication to support your requirements. However, there are important considerations and best practices to keep in mind: * HTTP Basic Authentication should only be used over HTTPS to protect credentials. Because credentials are sent with every request, it is less secure than OAuth 2.0. * OAuth 2.0 is the recommended modern standard for authorization. It provides better security through tokens and allows for [granular access control](../../../_glossary.md#term-granularity). * The implementation must be carefully designed to avoid conflicts between the two authentication methods. The order of authentication filters and proper configuration is critical. * Long-term, fully migrating to OAuth 2.0 and phasing out HTTP Basic Authentication lets you reduce complexity and improve overall security. In summary, while supporting multiple authentication methods simultaneously can be justified in some cases, it adds complexity. The recommendation is to prefer OAuth 2.0 as the more modern, secure protocol and only introduce HTTP Basic Authentication support thoughtfully for legacy compatibility when necessary. A clear roadmap to eventually standardize on OAuth 2.0 should be part of the plan. ## Related content * [Migrate from mTLS to OAuth Authentication in Confluent Platform](../oauth-oidc/migrate-from-mtls-to-oauth.md#migrate-acls-from-mtls-to-oauth) * [Migrate from LDAP to OAuth RBAC in a RBAC-enabled Confluent Platform Cluster](../../authorization/rbac/migrate-ldap-to-oauth-for-rbac.md#migrate-ldap-to-oauth-for-rbac)