# 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](overview.md#authenticate-overview). ## 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](user-identities/user-accounts/overview.md#user-accounts) for people signing in to the Confluent Cloud Console or Confluent CLI, and for development and testing. * Use [service accounts](workload-identities/service-accounts/overview.md#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](workload-identities/overview.md#workload-identities-overview). ### 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](user-identities/overview.md#user-identities-overview) | | External applications | A service account with an API key | [Use API Keys to Authenticate to Confluent Cloud](workload-identities/service-accounts/api-keys/overview.md#api-keys-overview) | | Flink statements and connectors that access Apache Kafka® topics | A service account without an API key | [Service Accounts on Confluent Cloud](workload-identities/service-accounts/overview.md#service-accounts) | | Enterprise workload identity integration | OAuth and OIDC identity pools | [Use OAuth/OIDC to Authenticate to Confluent Cloud](workload-identities/identity-providers/oauth/overview.md#oauth-overview) | | Certificate-based authentication | mTLS certificate identity pools | [Use Mutual TLS (mTLS) to Authenticate to Confluent Cloud Resources](workload-identities/identity-providers/mtls/overview.md#mtls-overview) | ### 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](../access-control/hierarchy/organizations/multiple-organizations.md#multiple-organizations). ### 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](user-identities/user-accounts/manage-local-user-accounts.md#manage-local-user-accounts) and [Manage Single Sign-On (SSO) User Accounts on Confluent Cloud](user-identities/user-accounts/manage-sso-user-accounts.md#manage-sso-user-accounts). ### 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](../access-control/rbac/predefined-rbac-roles.md#organizationadmin-role) 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](user-identities/user-idps/sso/az-oidc-sso.md#az-oidc-sso). For the full prerequisites and setup steps, see [Enable SAML SSO on Confluent Cloud](user-identities/user-idps/sso/enable-sso.md#enable-sso). ### What are the limitations of SSO on Confluent Cloud? Confluent Cloud has the following [Limitations](user-identities/user-idps/sso/enable-sso.md#sso-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](user-identities/user-idps/sso/group-mapping/overview.md#group-mapping). ### 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](user-identities/user-idps/sso/group-mapping/overview.md#group-mapping-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](../access-control/rbac/predefined-rbac-roles.md#organizationadmin-role) 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](user-identities/user-accounts/multi-factor-auth.md#multi-factor-auth) and [Require MFA with FIDO2 for your organization](user-identities/user-accounts/multi-factor-auth.md#require-mfa-for-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](../advanced-security.md#advanced-security-add-on). Enabling SCIM does not automatically turn off [just-in-time (JIT) user provisioning](user-identities/user-idps/sso/jit-user-provisioning.md#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](user-identities/user-idps/sso/jit-user-provisioning.md#jit-user-provisioning) and [SCIM User Provisioning on Confluent Cloud](user-identities/user-idps/sso/scim.md#scim-user-provisioning). ## 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](workload-identities/service-accounts/api-keys/overview.md#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](workload-identities/service-accounts/api-keys/overview.md#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](workload-identities/service-accounts/api-keys/overview.md#cloud-api-key-resource-scopes) and [Global API keys](workload-identities/service-accounts/api-keys/overview.md#cloud-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](../access-control/rbac/overview.md#cloud-rbac) and [ACLs](../access-control/acls/overview.md#acl-manage). For more information, see [API keys and Confluent Cloud accounts](workload-identities/service-accounts/api-keys/overview.md#cloud-api-key-ownership). ### 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](workload-identities/service-accounts/api-keys/overview.md#cloud-global-api-keys) and [Known limitations](workload-identities/service-accounts/api-keys/overview.md#global-api-key-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](workload-identities/service-accounts/api-keys/overview.md#api-keys-overview). ### 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](../../quotas/service-quotas.md#service-quotas-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](workload-identities/service-accounts/api-keys/manage-api-keys.md#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](workload-identities/service-accounts/api-keys/best-practices-api-keys.md#api-keys-best-practices). ### 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](workload-identities/service-accounts/api-keys/troubleshoot.md#troubleshoot-api-keys). ## 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](workload-identities/overview.md#workload-identity-providers-overview). ### 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](workload-identities/identity-providers/oauth/overview.md#oauth-overview). ### 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](workload-identities/identity-providers/oauth/identity-pools.md#set-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](workload-identities/identity-providers/oauth/troubleshooting.md#oauth-troubleshooting). ## 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](workload-identities/identity-providers/mtls/configure.md#mtls-requirements). ### How do I revoke a client certificate? 1. Revoke the certificate at your certificate authority (CA), which adds it to that CA’s certificate revocation list (CRL). 2. 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. 3. 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](workload-identities/identity-providers/mtls/certificate-revocation.md#certificate-revocation-mtls) and [Configure a CRL](workload-identities/identity-providers/mtls/certificate-revocation.md#configure-crl). ## Related content * [Manage Authentication on Confluent Cloud](overview.md#authenticate-overview) * [Control Access to Confluent Cloud Resources](../access-control/overview.md#control-access-overview) * [Confluent Cloud Security FAQ](../security-faq.md#cloud-security-faq) * [Best Practices for Using API Keys on Confluent Cloud](workload-identities/service-accounts/api-keys/best-practices-api-keys.md#api-keys-best-practices) * Confluent Developer: [Confluent Cloud Security course](https://developer.confluent.io/courses/cloud-security/)