Single Sign-on (SSO) for Confluent Cloud

Confluent Cloud allows for single sign-on (SSO) using your existing SAML-based identity provider (IdP). SSO provides access control for multiple independent software systems. With SSO, enterprise users can log in to multiple, unrelated systems using a single user ID and password, which means enterprises no longer have to store and manage passwords in company databases. SSO also improves security and decreases service and troubleshooting issues associated with individual logins.

In Confluent Cloud, SSO is enabled at the organization level. After SSO is enabled, the authentication behavior changes as follows:

  • All new invited users to the organization are authenticated using SSO (by default).
  • Once a user authenticates using SSO, they cannot be added as a local user in other organizations.


When SSO is disabled, the authentication method for users does not automatically change. Before you disable SSO, make sure that you have a local user account with the OrganizationAdmin role to be able to sign in to your organization.

For details about SSO user accounts, see Single sign-on (SSO) user accounts. Multi-factor authentication (MFA), including two-factor authentication (2FA), is an SSO option available from most identity providers.


  • You must have an existing SAML-based identity provider, such as Okta, OneLogin, or Azure Active Directory (AD).
  • Only users assigned the OrganizationAdmin role can view and modify SSO settings.


Identity provider-initiated sign-in flows for SSO are not supported. In an identity provider-initiated flow, Confluent Cloud cannot verify that an end user initiated the flow, which leaves users vulnerable to Cross-Site Request Forgery (CSRF) attacks. Several identity providers suggest workarounds to simulate identity provider-initiated login flows, such as the Okta bookmark application.

The SAML Single Logout (SLO) Protocol, including the Single Logout URL, is not supported in Confluent Cloud SSO.

SSO Terminology

The following terms play a key role in the implementation of SSO for Confluent Cloud:

Identity provider (IdP)
The service that stores and manages digital identities. SSO users are redirected to the identity provider for authentication.
Local user
Also known as a “non-SSO user”, this user possesses a password that is stored in the Confluent Cloud database and authenticates directly with Confluent Cloud. For details, see Local user accounts.
Service provider-initiated login
For a service provider-initiated login, users access the Confluent Cloud login page, and are then redirected to their identity provider to log in.
SSO user
The Confluent Cloud user who authenticates using their own identity provider.

Confluent Cloud SSO workflow

Web browser

With SSO enabled, users sign in at<sso-identifier>. The browser makes an OpenID Connect (OIDC) request to the identity broker at, which then redirects the browser to send a SAML request to the organization’s identity provider. After the user successfully authenticates, the identity provider responds with a signed SAML ID Assertion, which the identity broker translates into a JSON Web Token (JWT). Confluent Cloud uses this token to authenticate additional requests from the browser.


Confluent Cloud SSO workflow

Confluent CLI

When SSO is enabled and the confluent login command is issued, the following browser-based workflow is launched:

  1. Generates an HTTP server on localhost to receive the authentication callback.
  2. Initiates the SSO flow by navigating to in the browser.
  3. The browser automatically redirects the user to the identity provider sign-in page.
  4. After successfully signing in, the browser redirects the user back to localhost with a signed id_token.
  5. Confluent CLI uses the id_token to obtain a Confluent Cloud back-end session.


If the Confluent CLI is running on a server without a web browser (also known as a “jump” host”), then this flow does not work. In such cases, you must log in using the --no-browser option. For details, refer to Sign in to Confluent Cloud using SSO.

Sign in to Confluent Cloud using SSO

You can sign in to Confluent Cloud using the Confluent CLI or the Confluent Cloud Console.

For SSO-enabled organizations, you can sign in to your Confluent Cloud organization using the following Confluent CLI command with your SSO user account:

confluent login


  • For the “SSO” authentication method, the confluent login command does not prompt the user for a password. SSO relies on your identity provider for authentication.

If the Confluent CLI is running on a server without a web browser (also known as a “jump host”), then you cannot sign in using confluent login. In such cases, you must use the --no-browser option:

confluent login --no-browser

After running this command, you receive a printout of a URL, which you must copy and paste into a local browser. After you provide your credentials and successfully log in, the browser displays a code that you must copy and paste back into in the Confluent CLI. Your workflow should look like the following:

confluent login --no-browser
Updates are available for ccloud. To install them, please run:
$ confluent update

Enter your Confluent credentials:
Navigate to the following link in your browser to authenticate:

After authenticating in your browser, paste the code here:
#### The following code was copied and pasted from the browser #####
Logged in as
Using environment t21388 ("default")

Disable SSO

To disable SSO:

  1. In Confluent Cloud Console, open the sidebar menu and click ADMINISTRATION -> Single sign-on.

    The Single sign-on page displays.

  2. Scroll to the bottom of the Single sign-on page and click Disable.

When SSO is disabled, your organization’s team members will no longer be able to sign in using your identity provider, and must use Forgot Password to create a Confluent Cloud password.

To re-enable SSO, you must repeat the steps in Enable Single Sign-on (SSO) for Confluent Cloud.

Troubleshoot SSO

If you attempt to sign in for the first time after enabling SSO while you are still signed in to your identity provider, you might be signed in immediately and bypass the identity provider sign-in window. If this occurs, sign out of your identity provider session, then sign in using an incognito browser window.