# Use SASL/OAUTHBEARER Authentication Between Confluent Server Brokers and Kafka Clients in Confluent Platform ## SASL/OAUTHBEARER authentication in Confluent Platform Confluent Platform supports OAuth/OIDC for authentication across all its services and interfaces. For Confluent Server brokers, you can use the SASL/OAUTHBEARER mechanism to authenticate Kafka clients and other Confluent Platform services such as Schema Registry and Connect, or to enable Cluster Linking with Confluent Cloud clusters. Confluent Server brokers in Confluent Platform clusters support SASL/OAUTHBEARER authentication, a SASL-based mechanism for authenticating clients using OAuth tokens based on the JSON Web Token (JWT) standard, specified in [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). The Kafka client configuration experience is the same as the OAuth-based authentication used in Apache Kafka®. Additionally, Confluent Server brokers provide enhanced enterprise capabilities for OAuth/OIDC authorization. For example, group-based authorization can be used when OAuth/OIDC authentication is deployed with role-based access control (RBAC). #### NOTE Both the Confluent Server broker mechanism and the Apache Kafka® OAuth authentication are built on [KIP-768](https://cwiki.apache.org/confluence/display/KAFKA/KIP-768+-+OAuth+Authentication+for+Kafka). ## SASL/OAUTHBEARER authentication flow The SASL/OAUTHBEARER authentication flow lets a Kafka client authenticate to Confluent Server brokers using an OAuth token issued by an identity provider. Before configuring this flow, you must establish a trust relationship between the Confluent Platform cluster and an OIDC-compliant identity provider (IdP). This includes configuring Confluent Server brokers and all Confluent Platform services to accept IdP-issued OAuth tokens for authentication. Confluent for Kubernetes or Ansible Playbooks for Confluent Platform can automate the setup of a trust relationship. After you configure the Confluent Server brokers and Kafka clients to use SASL/OAUTHBEARER authentication, the following sequence diagram and steps describe a successful authentication flow between a Kafka client and Confluent Server brokers.  The SASL/OAUTHBEARER mechanism in Confluent Platform uses the OAuth client credentials grant flow, the same flow used for OAuth authentication in Apache Kafka® and Confluent Cloud. In the preceding sequence diagram, there are three main entities: * Confluent Server broker, which is integrated with an identity provider for enabling OAuth token-based authentication * Identity provider (OIDC-compliant) * Client application (for example, a producer or consumer application) The following steps describe the flow for a Kafka client: 1. The Kafka client requests an OAuth token from the identity provider by submitting its client credentials. 2. The identity provider validates the client credentials and, if successful, returns OAuth access to the client application. The OAuth token contains client identity details, including the principal and scope of the client application. 3. The Kafka client uses the OAuth token to request resource access (such as topic A) to the Confluent Server broker over SASL/OAUTHBEARER. 4. Confluent Server brokers retrieve the JWKS (JSON Web Key Set) keys when the first OAuth verification (OAuth call) happens and validates them for client authenticity. Configure Confluent Platform services to cache JWKS keys from the corresponding identity provider (IdP). You configure the expiration of JWKS keys on the IdP. If the JWKS keys expire on Confluent Platform due to a rotation policy or expiration, the services immediately fetch updated keys from the IdP to prevent authentication failures. 5. If the validation is successful, brokers authenticate the incoming client. 6. After the client authentication is successful, the client principal is extracted from the token and used for authorization using RBAC or access control lists (ACLs) specified on the Confluent Platform cluster. 7. If the client principal extracted from the OAuth token has access policies specified for requested topic A, then the client request for access to topic A is successfully authorized. 8. After successful authentication and authorization, the Kafka client can proceed with Kafka operations, such as producing or consuming messages. The client credentials grant flow (OpenID Connect specification and RFC 6749) is also triggered when OAuth/OIDC is enabled for authentication between clients (producers or consumers) and other Confluent Platform services, such as Schema Registry or REST Proxy, and for service-to-service communication between all Confluent Platform services, for example, between Schema Registry and Confluent Server brokers. The SASL/OAUTHBEARER authentication flow provides the following benefits: * The client identities are hosted on an OIDC-compliant identity provider, enabling centralized identity management and streamlined authentication. * The use of short-lived tokens enhances security. * Tokens carry specific permissions to enable [fine-grained](../../../../_glossary.md#term-granularity) access control. ## Related content * [Configure Confluent Server Brokers for SASL/OAUTHBEARER Authentication in Confluent Platform](configure-brokers.md#configure-sasl-oauthbearer-brokers) * [Configure Clients for SASL/OAUTHBEARER Authentication in Confluent Platform](configure-clients.md#configure-sasl-oauthbearer-clients) * [Use OAuth/OIDC for Authentication in Confluent Platform](../../oauth-oidc/overview.md#oauth-oidc-authentication-overview) * [Configure Metadata Service (MDS) in Confluent Platform](../../../../kafka/configure-mds/index.md#rbac-mds-config)