This page provides specific information about how authentication and authorization work in CXone. If this is the first time you've worked with these concepts, you should gain a basic understanding of authentication and authorization ideas and terminology first.
Once you've reviewed this material, you're ready to:
- Set Up CXone Authentication Using the Built-in Identity Provider
- Set Up CXone Authentication Using an External Identity Provider
When users log in to any application suite, including CXone, these two steps typically occur in the order shown:
- Authentication—Is the user who they claim to be?
- Authorization—Should the authenticated user have the access they've requested?
All users must be authenticated and authorized before they can access CXone.
Users can be people or applications. For example, chatbots and virtual assistants often run by means of a user account. Most application suites use the same processes for human and virtual users. In these online help pages about authentication and authorization, we've used the term user to apply to both people and applications. If there are differences, they're clearly explained.
Authentication can be complicated to set up and difficult to test and validate. To set up authentication in CXone, you need to understand:
How authentication works in CXone
The built-in CXone identity provider
External identity providers
Differences between authenticating human users and application users
You also need to know how authorization works in the CXone platform.
This illustration shows how CXone authenticates and authorizes users:
A user accesses CXone through a supported web browser.
CXone asks for the user's login credentials.
The user provides credentials.
CXone verifies them with an identity provider (IdP). CXone has its own built-in IdP, but it can also work with an external IdP.
Once the user is authenticated, the CXone Authorization Server provides access to the CXone platform. CXone does not support external authorization systems.
Authentication Using the Built-in Identity Provider
The built-in CXone IdP authenticates users with a username and password. Each username must be unique to your organization. You can optionally add multi-factor authentication (MFA) for an additional security layer.
Sometimes applications need access to CXone features and functionality. CXone treats these applications, like bots and interactive virtual assistants (IVAs), as users. Application users are only supported with built-in authentication. In addition, application users don't use login authenticators. Instead, they use access keys.
User Login with Built-in Authentication
Users first see a screen that asks for their username. Until CXone knows the username, it cannot ask for additional credentials. CXone can only ask for passwords or MFA tokens once it knows which user is logging in.
After the user enters their username and clicks NEXT, a new window asks for the user's password. Once the user enters their correct password and clicks Sign In, CXone authenticates the user and grants them access to the system.
This window looks slightly different for
Password criteria can be customized with login authenticators. With a login authenticator, you can control:
Number of characters required in a password
Types of characters required in a password
Number of days before the user has to reset their password
Number of wrong password attempts allowed before the account is locked
Number of passwords that CXone remembers, which prevents users from reusing those passwords
Passwords are not visible in CXone. For privacy and security, passwords are maintained internally and can only be changed using a forgot password or resent password flow. Users can use the link on the password login screen and follow the on-screen instructions. Users will receive an email notifying them if their password has been changed.
CXone comes with a default login authenticator you can use if you don't need custom login authenticators. You still must assign this default authenticator to the
You can set up as many custom login authenticators as you'd like. For example, you can require more complex passwords for users that have access to valuable information. Any time you want to make an authentication requirement different for a user account, you'll need to create a new login authenticator. Changes to authenticators apply to assigned users the next time they log in.
You can also set up multi-factor authentication (MFA) with custom login authenticators. MFA increases your security by adding another layer of authentication. For example, you could have your users authenticate with a username and password. Then, you could have them authenticate again with a code sent to their mobile devices. These codes are typically known as MFA tokens, even when a physical token is not involved.
CXone supports both major types of MFA:
- Time-based—typically used by software authenticators like Google
- Counter-based—typically used by hardware tokens
You can enable MFA for login authenticators with a single checkbox. However, the specific information about users, their MFA settings, and their identities is maintained in the individual employee account.
Login authenticators and security profiles are completely separate. This means an employee's authentication method has no relation to what they can access in CXone.
When you sign in to a system with an account from another site, you're using external authentication. For example, you might log in to an app on your phone with your Google account.
External authentication, sometimes called federation, uses an external identity provider (IdP) to help authenticate users. The external IdP works with the CXone IdP to authenticate the user. To work together, both IdPs rely on authentication protocols.
CXone supports both hosted and cloud service identity providers.
You should be familiar with your identity provider. If not, work with your company team that manages authentication. Setting up federation can be difficult if the right people are not involved. Your organization may have established processes for integrating systems like CXone with your identity provider. Following these processes and meeting your specific security needs is your responsibility. The NICE CXone team is here to support you along the way.
Authentication protocols establish communication and trust between different IdPs. CXone supports these authentication protocols:
- OpenID Connect
- SAML 2.0
OpenID Connect has more features and is easier to support. Benefits include:
Allows seamless IdP integration that's transparent to users
Enables a range of multi-factor authentication (MFA) options
Scalable foundation for a platform service model
OpenID Connect validates authentications with public/private certificate signing using an industry standard called JWKS. Therefore, OpenID Connect configuration determines how the public certificates are obtained. Trust with the certificate issuer is established using a client identifier and secret.
SAML 2.0 is an older technology that can cause integration problems. However, it is currently more widely used than OpenID Connect. Your organization may have guidelines on which protocol should be used. In general, they both offer a similar user experience and underlying level of security.
Both OpenID Connect and SAML 2.0 support service provider (SP)-initiated authentication flow. This is a familiar flow and the model used by many apps and websites. The user experience is:
- Users enter their credentials in CXone (that is, they log in).
- CXone uses its built-in IdP to communicate with your external IdP to verify the user identity.
- CXone uses its built-in authorization to verify the authenticated user's access levels.
- CXone provides correct access to the authenticated, authorized user.
SAML 2.0 also supports the less-common identity provider (IdP)-initiated flow. In this flow, your user enters their credentials with your identity provider. Then, the identity provider launches CXone.
For SAML 2.0, CXone only supports signing the Message/Response, not the Assertion.
IdP-initiated flows apply to single applications, not the entire CXone suite. For example, you can use this flow to launch the main user interface applications, but you cannot use it to launch other applications like Studio. For the entire suite to function seamlessly, the SP-initiated flow is required.
Your users may be familiar with either or both of these authentication flows. If you use SAML 2.0, then be aware of the limitations presented by each flow. These are discussed more in the next section. OpenID Connect always uses the SP-initiated flow.
CXone does not support additional encryption offered by some authentication protocols.
Configuration details differ based on the IdP and authentication protocol you choose. It's not possible to cover all possible combinations of IdPs and authentication protocols, but a few common scenarios are discussed in the information that follows.
The CXone suite does not support every combination of application, external IdP, and authentication protocol. In some cases, support doesn't exist. In other cases, there are limitations with workarounds. It's difficult to show potential issues for every combination and scenario, so you should do a test setup with your identity provider. Your test should take into account your different use cases and user flows. The following table can help guide your evaluation.
|CXone Application||External IDP||Authentication Protocol||Limitations and workarounds|
|CXone Platform and All Applications||All||All||Does not support encryption of claims.|
|CXone Platform and All Applications||All||SAML 2.0||Only message signing is supported. Public certificate must be included in the response.|
|CXone Platform||Azure AD||SAML 2.0||Only IdP-initiated flow is supported.|
Only the main web applications support the IdP-initiated SAML 2.0 flow. Users who need access to Studio or the various agent applications must use built-in authentication or an SP-initiated flow.
Identity providers must trust each other before they can communicate. Each provider must have information about the other. What information is required depends on the authentication protocol. How the information is obtained depends on the IdP.
Trust in OpenID Connect
Your CXone Account Representative will work with you to configure a trusted relationship between your CXone business unit High-level organizational grouping used to manage technical support, billing, and global settings for your CXone environment and your external IdP using OpenID Connect.
Trust in OpenID Connect involves these values, which you'll need in order to configure the relationship:
- Issuer—This value always looks like a URL.Issuer values vary depending on your external IdP, but they always look like a URL. For example, Google can work as an external IdP and it supports OpenID Connect. The Google issuer is https://accounts.google.com. Many external IdP providers make their issuer URLs discoverable by appending ".well-known/openid-configuration" to the end of the primary URL for the IdP. This often provides you with additional valuable information from the IdP. The following image shows the types of information provided in this way by Facebook at https://www.facebook.com/.well-known/openid-configuration:
- Client Identifier—This value is assigned by your external IdP for you to use with CXone. During authentication, it lets the IdP know what application is trying to authenticate.
- Client Secret—This value ensures the authentication is secure and helps ensure malicious actors cannot use the external IdP to authenticate into your CXone
business unit. CXone supports only client_secret_basic and client_secret_post.
Trust in SAML 2.0
There are several configuration parameters used to establish trust with SAML 2.0. Work with your CXone Account Representative to use these parameters to create a trusted relationship between your CXone business unit High-level organizational grouping used to manage technical support, billing, and global settings for your CXone environment and your external IdP.
A pre-populated, non-editable global unique ID that your external IdP may require you to enter on their side when using the SAML 2.0 protocol. The IdP includes it as the entity ID of the issuer in the SAML 2.0 request message. Some IdPs, including Okta and OneLogin, don't require you to configure the entity ID on their side. Others, including Salesforce, do.
The endpoint URL provided by your IdP.
A pre-populated, non-editable URL your IdP requires to set up any SAML 2.0 flow. It serves as an endpoint URL for receiving and parsing an authentication assertion. You must enter this ID in your IdP configuration, usually in the ACS URL field. Some IdPs call it something other than ACS. For example, in the Okta SAML 2.0 template, you enter this URL in the Single Sign On URL field.
|Certificate||Your IdP will provide you with a security certificate.|
Authentication of Applications
Users and applications are authenticated in very similar ways. The main difference is that applications are authenticated with an access key while users are authenticated with a username and password. Unlike users, applications are not required to interact through a browser. They can function in a back-office environment.
You can create
Authorization in CXone
Authorization is the process of verifying what resources a user is allowed to access. Resources can include applications, files, and data. You can define users' access to resources with
A user's authentication method doesn't impact authorization. CXone uses the same authorization process for all users. It doesn't matter whether they are authenticated with access keys or passwords.