Confluent Cloud Identity FAQ

Confluent Cloud authenticates two kinds of identities: human users and workloads. Human users authenticate with local password, Google or GitHub account, or Single Sign-On (SSO) with an external identity provider. Workloads can authenticate with API keys, OAuth/OIDC, or mutual TLS (mTLS) using service accounts, OAuth identity pools, and certificate identity pools respectively.

For an overview of the authentication options, see Manage Authentication on Confluent Cloud.

General identity

What is the difference between a user account and a service account?

A user account represents a human. A service account represents an application or service that needs programmatic access to Confluent Cloud resources.

Use user accounts for people signing in to the Confluent Cloud Console or Confluent CLI, and for development and testing.
Use service accounts for applications, connectors, Apache Flink® statements, and automation such as Terraform.

User accounts, service accounts, and identity pools are organization-level resources, meaning they can be granted access to resources across environments in your organization.

For more information, see Workload Identities and Identity Providers on Confluent Cloud.

Which authentication method should I use?

Choose your authentication method based on which identity is authenticating:

Identity	Authentication method	Learn more
Human users	Local user accounts or SSO using a SAML identity provider	User Identities on Confluent Cloud
External applications	A service account with an API key	Use API Keys to Authenticate to Confluent Cloud
Flink statements and connectors that access Apache Kafka® topics	A service account without an API key	Service Accounts on Confluent Cloud
Enterprise workload identity integration	OAuth and OIDC identity pools	Use OAuth/OIDC to Authenticate to Confluent Cloud
Certificate-based authentication	mTLS certificate identity pools	Use Mutual TLS (mTLS) to Authenticate to Confluent Cloud Resources

Can I use one user account in more than one Confluent Cloud organization?

Yes. A single email address can be a user in multiple Confluent Cloud organizations; however, an existing user cannot use their email address to sign up for Confluent Cloud, even if they have not signed up before.

You can switch between the organizations in the Confluent Cloud Console with the same email address. For details, see Manage Multiple Organizations on Confluent Cloud.

Does Confluent Cloud support Kerberos?

No. Confluent Cloud does not support Kerberos authentication.

SSO

What is the difference between a local user account and an SSO user account?

A local user account is created directly in Confluent Cloud and authenticates with a username and password that Confluent Cloud manages.

An SSO user account authenticates through your own SAML identity provider, which owns the credentials and the sign-in experience.

For more information, see Manage Local User Accounts on Confluent Cloud and Manage Single Sign-On (SSO) User Accounts on Confluent Cloud.

Which identity providers can I use for SSO?

You can use any SAML-based identity provider, such as Okta, OneLogin, or Microsoft Entra ID. Only users with the OrganizationAdmin role can view or change SSO settings.

Note

If you created your organization through Azure Marketplace, Confluent automatically configures the organization to use the associated Microsoft Entra ID with Confluent-managed OIDC SSO. To use a SAML identity provider instead, disable and then re-enable SSO in the Confluent Cloud Console. For more information, see Use Single Sign-On with Azure Marketplace on Confluent Cloud.

For the full prerequisites and setup steps, see Enable SAML SSO on Confluent Cloud.

What are the limitations of SSO on Confluent Cloud?

Confluent Cloud has the following Limitations:

Confluent Cloud does not support the SAML Single Logout protocol, including the Single Logout URL.
SSO connection names must be globally unique. If you have multiple Confluent Cloud organizations, you can’t reuse the same SSO connection name across organizations.

Can I map groups from my identity provider to Confluent Cloud roles?

Yes. Group mapping links user groups from your SAML identity provider to Confluent Cloud role-based access control (RBAC) roles and access control lists (ACLs). Confluent Cloud supports basic group mappings of a user group to a set of permissions, as well as advanced group mappings that use Common Expression Language (CEL) expressions for filtering a set of user groups.

For more information, see Group Mapping on Confluent Cloud.

Why doesn’t my API key have the permissions from my group mapping?

An API key associated with an SSO user account has only the permissions assigned directly to that user, not the permissions granted through group mappings. Confluent Cloud grants group mapping permissions to an SSO user account only after the user signs in through SSO.

This is one reason to use service accounts rather than user accounts for production workloads. For more information, see Limitations.

Does Confluent Cloud support multi-factor authentication?

Yes. Confluent Cloud supports multi-factor authentication (MFA) with FIDO2 for local user accounts, using a security key, a biometric authenticator, or a passkey. MFA is optional by default. A user with the OrganizationAdmin role can require it for all local user accounts in the organization.

If you authenticate through SSO, you get MFA from your identity provider instead.

For more information, see Manage Multi-Factor Authentication with FIDO2 for Local User Accounts on Confluent Cloud and Require MFA with FIDO2 for your organization.

Can I provision users automatically when they first sign in?

Yes. Just-in-time (JIT) user provisioning creates a Confluent Cloud user account the first time a user successfully authenticates through your SSO identity provider, so you don’t have to invite each user individually. With System for Cross-domain Identity Management (SCIM) user provisioning, your IdP becomes the single source of truth for Confluent Cloud single sign-on (SSO) user accounts, automating provisioning and de-provisioning. SCIM does not affect local user accounts, which you continue to manage in Confluent Cloud. To use SCIM, you must turn on the Advanced Security add-on.

Enabling SCIM does not automatically turn off just-in-time (JIT) user provisioning. If both are enabled, a user who signs in with SSO can still be provisioned through JIT. To make your IdP the sole source of new SSO user accounts, turn off JIT user provisioning. For more information, see Just-in-time User Provisioning on Confluent Cloud and SCIM User Provisioning on Confluent Cloud.

API keys

What does an API key consist of?

Each API key consists of an API key ID and an API secret. Use the API key ID as the username in client configurations. The API key ID is not secret. The API secret is confidential. Confluent Cloud displays the secret only once, at creation, and you cannot retrieve it afterward. If you lose the secret, create a new key.

For more information, see API key format.

Why do some API secrets start with `cflt`?

Starting July 30, 2025, API secrets include a cflt prefix so that secret scanning tools can detect Confluent secrets that are accidentally committed to code, logs, or configuration files. The prefix appears only in secrets, not in API key IDs. Secrets created before that date might not have the prefix. Both formats continue to work.

For more information, see API key format.

What resource scopes can an API key have?

You can create API keys scoped to a Kafka cluster, Schema Registry, a ksqlDB cluster, a Flink region, Tableflow, cloud resource management, or your entire organization.

A global API key allows you to authenticate across multiple Confluent Cloud resources with a single credential.

For details on each scope, see Resource scopes and Global API keys.

Do API keys carry their own permissions?

No. Permissions belong to the user account or service account that owns the key, not to the key itself. An API key can do only what its owning principal is authorized to do through RBAC role bindings and ACLs.

For more information, see API keys and Confluent Cloud accounts.

What is a global API key? When should I use it?

A global API key authenticates across multiple Confluent Cloud services with a single credential, which simplifies development, Terraform-managed infrastructure, and multi-cluster failover scenarios. Like any other key, it grants no permissions on its own.

Each user account or service account can create only two global API keys. Global API keys count against the Kafka API key quota of every supported cluster. When you need access to only one resource, use a resource-scoped key.

For more information, see Global API keys and Known limitations.

Can I use the same API key in different environments?

It depends on the API key. API keys are typically scoped to specific Kafka clusters and environments, so you need a separate key for each environment. However, a global API key works across Confluent Cloud services and resources based on the principal’s assigned permissions.

For more information, see Use API Keys to Authenticate to Confluent Cloud.

How many API keys can I create?

A service quota limits the number of API keys per user account or service account. For the current limits, see API keys.

What happens to API keys when I delete an account?

When you delete a user account or a service account, Confluent Cloud revokes all access by that account, including access through any API keys associated with it. Before deleting an account, confirm that the account’s API keys are not in active use. To list the keys owned by an account, see View API keys.

How should I manage API keys securely?

Create a separate service account and key for each application or use case, so retiring one key affects only that application. This approach also limits any damages from leaked credentials to a single application.
Avoid API keys tied to user accounts in production, because a user’s access can change and the key is deleted along with the user.
Store secrets in a secrets manager.
Rotate keys regularly and delete unused keys.

For the full list, see Best Practices for Using API Keys on Confluent Cloud.

My client fails to authenticate with an API key. What should I check?

Verify that the key is scoped to the resource you are calling.
Ensure the owning principal has the necessary RBAC roles or ACLs.
Check that the secret was copied completely.

For a walkthrough of common failures, see Troubleshoot API Key Issues on Confluent Cloud.

OAuth and identity pools

What is an identity pool?

An identity pool is a Confluent workload principal that, like a service account, can be granted access to Confluent Cloud resources. Use an identity pool when the workload authentication method is OAuth or mTLS. Each identity pool can only be authenticated by a single configured identity provider, which is the one under which the identity pool was created.

Claims in the OAuth token or metadata in the X.509 client certificate map to one or a set of identity pools after the token or certificate is authenticated. The identity pool is used as the identity for the workload operations. Authorization is limited to the RBAC roles and ACLs assigned to the identity pool.

Confluent Cloud supports OAuth and OIDC identity pools and mTLS certificate identity pools. For more information, see Workload identity providers.

How is OAuth different from an API key?

OAuth uses short-lived tokens issued by your own identity provider, while API keys are long-lived static credentials that authenticate directly. With OAuth, your identity provider manages credentials centrally and tokens expire automatically. When you already run an enterprise identity provider and want workload credentials to follow it, use OAuth.

For more information, see Use OAuth/OIDC to Authenticate to Confluent Cloud.

How do I control which tokens an identity pool accepts?

To control which tokens an identity pool accepts, set a filter on the pool. The filter is a CEL expression evaluated against the claims in the token. You can restrict a pool to a specific subject, audience, group, or any other claim your identity provider issues.

For examples, see Set OAuth identity pool filters.

My OAuth clients cannot authenticate. What should I check?

Check that the JSON Web Key Set (JWKS) URI is reachable from Confluent Cloud.
Ensure the token’s claims match the identity pool filter.
Verify the audience and issuer match the identity provider configuration.
Check that the pool has the roles or ACLs it needs.

Confluent Cloud records authentication events in audit logs.

For a structured troubleshooting path, see Troubleshoot OAuth/OIDC Issues on Confluent Cloud.

mTLS questions

Which cluster types support mTLS?

mutual TLS (mTLS) authentication with certificate revocation list (CRL) support is available on these cluster types:

Dedicated clusters on AWS, Azure, and Google Cloud
Enterprise clusters on AWS
Freight clusters on AWS

For the current region availability, see Requirements.

How do I revoke a client certificate?

Revoke the certificate at your certificate authority (CA), which adds it to that CA’s certificate revocation list (CRL).
Set the require_crl_on_client_certificate attribute on the CA resource to true. Confluent Cloud enforces fail-close CRL checking only when this attribute is enabled.
Attach the CRL as a URL or a PEM file to the corresponding CA resource in Confluent Cloud.

Confluent Cloud checks the CRL during the mTLS handshake and rejects any certificate listed there. Any existing client connection with a revoked certificate will also be terminated.

For more information, see Certificate revocation for mTLS authentication on Confluent Cloud and Configure a CRL.