Use OAuth/OIDC to Authenticate to 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.
Tip
If you’re curious to learn about OAuth for Kafka and the centralized identity management system, check out the following podcast:
Limitations¶
OAuth 2.0 for Confluent Cloud includes the following limitations:
- Authentication to Standard, Enterprise, and Dedicated Kafka clusters is supported.
- 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 JWT credentials, see:
- JWT (JSON Web Tokens) website, provided by Auth0
- Introduction to JSON Web Tokens
- JWT Debugger
- JWT Handbook: a free ebook
- JSON Web Token (JWT) [RFC 7519]
- JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [RFC 9068].
OAuth 2.0 flow¶
At a high-level, the following diagram shows a sample OAuth flow for an organization.
Here is a summary of the steps in the OAuth 2.0 flow:
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.
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.
For details, see Use Identity Pools with Your OAuth/OIDC Identity Provider on Confluent Cloud.
Configure clients.
To configure your clients:
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.
The client requests a JSON Web Token (JWT) from the identity provider using the Client Credentials Grant.
Use the Access Token.
The Kafka client (
SASL/OAUTHBEARER
) sends the token to Confluent Cloud.Producer/Consumer configuration example:
bootstrap.servers=<bootstrap-URL> security.protocol=SASL_SSL sasl.oauthbearer.token.endpoint.url=https://myidp.example.com/oauth2/default/v1/token 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='<client-id>' scope='<requested-scope>' clientSecret='<client-secret>' extension_logicalCluster='<cluster-id>' extension_identityPoolId='<pool-id>';
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" }