OAuth for Confluent Cloud

Confluent OAuth supports the OAuth 2.0 protocol for authentication and authorization. OAuth is an open-standard protocol that grants access to supported clients using a temporary access token. Supported clients use delegated authorization to access and use Confluent Cloud resources and data on the behalf of a user or application.

Summary of key features provided by OAuth 2.0 support in Confluent Cloud:

  • Manage application identities and credentials through your own identity provider.
  • Authenticate with Confluent Cloud resources using short-lived credentials (JSON Web Tokens).
  • Confluent Cloud’s OAuth 2.0 service provides OIDC-based tokens for authentication and authorization that are based on the OAuth 2.0 Authorization Framework [RFC 6749] and is compliant with OpenID Connect (OIDC).
  • Use identity pools to map group and other attributes to policies (RBAC or ACLs).
  • You can configure OAuth using the Confluent Cloud Console, Confluent CLI, and REST API.
  • You can automate end to end using the OAuth REST API.

Limitations

Important

Limited Availability

OAuth for Confluent Cloud is a fully supported offering in Limited Availability to a subset of Confluent customers. To be considered for access before General Availability, contact Confluent Support.

OAuth 2.0 for Confluent Cloud includes the following limitations:

  • Authentication to Kafka clusters is supported.
  • Available only for Dedicated clusters. Support for Standard clusters will be included by General Availability.
  • ACLs for identity pools can be managed only by using Confluent CLI and the REST API.
  • Supported clients include:
    • Apache Kafka client: 3.2.1 or later;
    • Confluent Platform: 7.2.1 or later; 7.1.3 or later
    • librdkafka: 1.9.2 or later

For default OAuth service limits, see:

Access token format

Confluent Cloud only accepts JSON Web Token (JWT) access tokens, based on an open, industry standard for representing claims to be transferred securely between two parties. A JWT is a string that represents a set of claims as a JSON object in a JSON Web Signature (JWS) or JSON Web Encryption (JWE) structure, enabling the claims to be signed or encrypted.

Each JWT includes a header, body, and signature that is formatted like this:

header.body.signature

For details about how JWT credentials, see:

OAuth 2.0 flow

At a high-level, the following diagram shows a sample OAuth flow for an organization.

../../../_images/oauth-oidc-flow.png

Here is a summary of the steps in the OAuth 2.0 flow:

  1. Establish trust between Confluent and your identity provider.

    To establish trust, you need to add the identity provider.

    • Define the type of identity provider.
    • Create a trust relationship between Confluent and your identity provider.
    • Add the claims to be used for authentication and authorization.
  2. Configure your identity pool and access policy.

    An identity pool is a group of external identities that are assigned a certain level of access based on policy.

  3. Configure clients.

    To configure your clients:

    1. Configure the Client ID and Client Secret in the Kafka client.

      The identity provider generates a Client ID and Client Secret and gives them to the client to use for all future OAuth exchanges.

    2. The client requests a JSON Web Token (JWT) from the identity provider using the Client Credentials Grant.

    3. Use the Access Token.

      The Kafka client (SASL/OAUTHBEARER) sends the token to Confluent Cloud.

      Producer/Consumer configuration example:

      bootstrap.servers=
      security.protocol=SASL_SSL
      sasl.oauthbearer.token.endpoint.url=https://
      sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler
      sasl.mechanism=OAUTHBEARER
      sasl.jaas.config=
      org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
      clientId=''
      scope=''
      clientSecret=''
      extension_logicalCluster=''
      extension_identityPoolId='';
      
    4. Confluent Cloud validates the token received based on the trusted JSON Web Key Set (JWKS), extracts the authenticated ID (sub) or other configured claim, extracts the authorization ID (pool ID), and maps to the authorization policy.

      JSON Web Token (JWT) example:

      {
        "ver": 1,
        "jti": "AT.-u7tKPqYmJm2t2wZgHnzKVOCY6Hy51y2ohXdRX0Z1gQ",
        "iss": "https://mycompany/oauth2/default",
        "aud": "mycompany-okta",
        "iat": 1617050423,
        "exp": 1617054023,
        "cid": "0oa1xn4ddcJb2GyFN4x7",
        "groups": [
          "Marketing",
          "ProjectA"
        ],
        "sub": "0oa1xn4ddcJb2GyFN4x7"
      }