.. title:: Configure OAuth authentication using SASL/OAUTHBEARER .. meta:: :description: Learn how to configure OAuth authentication for Confluent Platform. .. _cp_oauth_authentication: Configure OAuth Authentication using SASL/OAUTHBEARER ##################################################### .. _ea-note-oauth-support: .. note:: **Early Access Program for OAuth Support** OAuth support for |cp| is currently available in an Early Access Program. An Early Access Program feature is a component of |cp| introduced to gain feedback. This feature should be used only for evaluation and non-production testing purposes or to provide feedback to Confluent. Early Access Program features are intended for evaluation use in development and testing environments only, and not for production use. The warranty and Support Services provisions of your agreement with Confluent do not apply to Early Access Program features. Confluent may discontinue providing preview releases of the Early Access Program features at any time at Confluent's sole discretion. Overview ******** OAuth 2.0 support for |cp| lets you "Bring Your Own Identity" to |cp|, leveraging your identity provider (IdP) to authenticate users and client applications. OAuth 2.0 provides a more secure and convenient way to grant access to your |ccloud| resources for your users and client applicaitions. OAuth 2.0 is an open standard for authorization that enables third-party applications to obtain limited access to web services. Auth 2.0 also provides authorization flows for web and desktop applications, and mobile devices. Confluent Server OAuth support ------------------------------ OAuth support for |cp| provides the following benefits: * LDAP independence for Confluent Server RBAC * OAuth support for MDS REST APIs. If you have OAuth-OIDC JWTs, you can use the MDS REST APIs directly for administrative operations using OAuth. * Support for migration and upgrade scenarios to enable client authentication and authorization with both OAuth as well as LDAP/mTLS, etc. * Token-based group management for RBAC where OAuth-OIDC JWTs serve as the source of groups. * Client applications, like producers and consumers, can use OAuth-OIDC JWTs to authenticate and authorize to the Confluent Server. * In addition to the OAuth support described in KIP-768, |cp| supports OAuth for enterprise features, like RBAC and group authorization. * You can Bring Your Own Identity (IdP) to Confluent Server with OAuth support. Limitations ----------- The following limitations apply to OAuth support for |cp| during the Early Access Program: * OAuth support for |cp| is available in |cp| 7.6 as an :ref:`Early Access feature `. that provides a minimal |cp| configuration (consisting of a |ak| broker and MDS), which lets you build applications that effortlessly produce and consume data through |ak| brokers, with RBAC authorization managed by MDS. * Ansible and CFK support for orchestration and management is currently unavailable. .. _configure-oauth-ak-brokers: Configure |ak| brokers ********************** To use OAuth authentication with |cp|, you must configure |ak| brokers with a SASL/OAUTHBEARER listener. * You can use the OIDC discovery endpoint to get the values for your IdP's JWKS URI , token endpoint (), and other values. Typically, the OIDC discovery endpoint is located at ``https:///.well-known/openid-configuration``. * Verify if the claim value for ``groups`` is compatible with the token configuration in your identity provider. The following example shows how to configure |ak| brokers with a SASL/OAUTHBEARER listener. Replace the values in angle brackets with the values for your IdP. .. code-block:: # Configuring a new listener listeners=..,EXTERNAL://:9095 advertised.listeners=..,EXTERNAL://:9095 listener.security.protocol.map=...,EXTERNAL:SASL_PLAINTEXT # Adding OAuth to the Kafka listener listener.name.external.sasl.enabled.mechanisms=OAUTHBEARER listener.name.external.sasl.oauthbearer.jwks.endpoint.url=https://my-good-idp.com/oauth2/keys listener.name.external.sasl.oauthbearer.expected.audience=api://default listener.name.external.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required; listener.name.external.oauthbearer.sasl.server.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler listener.name.external.principal.builder.class=io.confluent.kafka.security.authenticator.OAuthKafkaPrincipalBuilder confluent.oauth.groups.claim.name=groups Optionally, you can use the SASL/OAUTHBEARER listener as the interbroker listener, using the following configuration: .. code-block:: inter.broker.listener.name=EXTERNAL sasl.mechanism.inter.broker.protocol=OAUTHBEARER listener.name.external.sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler listener.name.external.sasl.oauthbearer.token.endpoint.url= listener.name.external.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ clientId="" \ clientSecret="" scope=""; # scope is optional When you use SASL/OAUTHBEARER as the interbroker listener, ensure that the principal in the authentication token of the client serves as the superuser. To do this, add the following configuration: .. code-block:: super.users= ...;User: # usually User: .. _configure-oauth-kraft-mode: Configure for KRaft mode ************************ When you use |cp| in KRaft mode, you must add the following configuration to the |ak| controller for group-based authorization to work: .. code-block:: listener.name.external.principal.builder.class=io.confluent.kafka.security.authenticator.OAuthKafkaPrincipalBuilder confluent.oauth.groups.claim.name=groups .. _configure-oauth-ak-clients: Configure |ak| clients ********************** To use OAuth authentication with |cp|, you must configure |ak| clients with the following properties: .. code-block:: sasl.mechanism=OAUTHBEARER security.protocol=SASL_PLAINTEXT sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler sasl.login.connect.timeout.ms=15000 # optional sasl.oauthbearer.token.endpoint.url= sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ clientId="" \ clientSecret="" scope=""; # optional * Scope is optional, but is required when your identity provider does not have a default scope or your groups claim is linked to a scope. Configure |ak| console consumer clients --------------------------------------- Client configurations are passed in the client properties file. To use OAuth authentication with |ak| console consumer clients, you must add the following properties to your clients: .. code-block:: ./bin/kafka-console-consumer \ --bootstrap-server :9095 \ --topic purchases \ --consumer.config oauth-client.properties .. _configure-mds-oauth-support: Configure MDS for OAuth support ******************************* Similar to your |ak| broker configurations, the following settings are required to enable IdP-issued OAuth token validation in MDS. For details on these configurations, see configurations for supporting IdP tokens in MDS. .. code-block:: confluent.metadata.server.user.store=OAUTH confluent.metadata.server.oauthbearer.jwks.endpoint.url= confluent.metadata.server.oauthbearer.expected.issuer= confluent.metadata.server.oauthbearer.expected.audience=Confluent,api://default,https://my-company.com confluent.metadata.server.oauthbearer.sub.claim.name=sub confluent.metadata.server.oauthbearer.groups.claim.name=groups * Group claims are included by default — you need to verify if the claim value for ``groups`` is compatible with the token configuration in your identity provider. Configure MDS for TLS ----------------------- If your identity provider uses a self-signed certificate and not one from a CA authority, you must add the identity provider's TLS certificate to the MDS truststore. To reload the truststore with the TLS certificate, you must restart Confluent Server (``confluent-server``). For details, .. see :ref:`add-identity-provider-tls-certificates-to-mds-truststore`. For development environments, you can use ``http`` (instead of ``https``) to connect to your identity provider. For production environments, you should use an ``https`` URL in your configurations. Configure MDS to enable OAuth without LDAP ------------------------------------------ Basic authentication (username:password) is not supported in this case. To interact with MDS requires a token from your identity provider. .. code-block:: confluent.metadata.server.user.store=OAUTH Configure MDS to enable OAuth with LDAP --------------------------------------- You can configure MDS to enable OAuth support without removing LDAP. This is mainly useful for client migration scenarios, and should be removed after migration. .. code-block:: confluent.metadata.server.user.store=LDAP_WITH_OAUTH .. _add-groups-in-idps: Add groups in identity providers ******************************** Depending on your identity provider, you might need to add groups to the token claims. .. tabs:: .. tab:: Okta Applications cannot be added to user group in Okta. However, Okta provides an application ``profile`` that you can use as an identity attribute in an access token. This operation cannot be performed using the Okta UI, but is available using their APIs. Here is a sample cURL request to create an application: .. code-block:: curl --location 'https://my-org.okta.com/api/v1/apps' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --header 'Authorization: SSWS ' \ --data '{ "name": "oidc_client", "label": "Sales Producer Application", "signOnMode": "OPENID_CONNECT", "credentials": { "oauthClient": { "token_endpoint_auth_method": "client_secret_post" } }, "profile": { "groups": ["ads", "fb-ads", "marketing-team"] }, "settings": { "oauthClient": { "client_uri": null, "logo_uri": null, "response_types": [ "token" ], "grant_types": [ "client_credentials" ], "application_type": "service", "consent_method": "REQUIRED", "issuer_mode": "ORG_URL" } } }' In the above example, the ``profile`` attribute is used to add groups to the token claims. The ``groups`` attribute is an array of groups that you want to add to the token claims. In this example, three groups called "ads", "fb-ads", and "marketing-team" are added to profile of "Sales Producer Application". For more information, see `Add application `__ in the Okta documentation. To configure the claim in the Okta UI, go to **Security → API → → Claims** and enter the claim name (``groups``) and your own expression for the value (for example, ``app.profile.groups``). .. tab:: Keycloak A group can be assigned to a client/service application in Keycloak identity provider. To add a group, select your client from the clients list, add it to user groups and add a corresponding token mapper. To add a client application to a user group in the Keycloak UI, #. Go to **Clients > Client details > Service accounts roles** and click the link in the information message. #. Add a token mapper to get the groups in the token. Go to **Clients > Client details > Client scopes > Add Mapper > By Configuration** and click **Create**. A custom claim ``groups`` can be added to the token of ``client_app1``. You can choose the name of the claim based on your use and configuration. You should keep same claim name for human user's ID token (for SSO) as well as the client application.