App Registration API

This service manages integrations with the CXone platform. Eventually there may be multiple integrations, for now only Applications are supported.

  • Applications. These represent applications that use the CXone platform APIs, whether integrated directly into the suite or not. Applications allow the use of authentication APIs and management of CORS policy configuration to allow other API calls.

Applications

Applications contain information necessary to manage authentication using OAuth2 and OpenID Connect flows with CXone. They also contain information necessary for CORS configuration, enabling other APIs to be called from a browser.

These integrations require a client identifier (client_id) and for confidential and back-end applications a client secret (client_secret). These are both assigned by the service. The service provides the following features for applications:

  • Enabling and disabling. Disabled applications are not allowed to authenticate or make API calls.
  • Ownership and notification. Applications are associated with a tenant, and also require notification addresses.

Applications are either public or confidential (see section 2.1 of the OAuth 2 specification). Public applications are those not capable of maintaining the confidentiality of their assigned client secret, and so no client secret is assigned to them. This restricts these applications to using the PKCE extension to authenticate. CXone introduces a third type of application called back-end that is a further restriction of confidential clients that do not use a browser. This means that certain fields are not required and restricts these applications to using only the OAuth2 /token endpoint for authentication. See the CXone Application Registration page for more information.

The type of the application is assigned during creation and cannot be changed. The application type also determines whether certain other fields are required or if they are assigned during creation - like the client secret.

Applications are also assigned a tenancy (either all or single). Single-tenant applications can only be used in the same tenant that registered the application. These are common for back-end applications or tools developed by a customer for automation. All-tenant applications can be used to authenticate users in any tenant. Applications that are registered as all-tenant require an offline approval process. They are then updated manually. The tenancy of an application cannot be modified after registration. During the approval process the application will exist as and operate as single-tenant.

For confidential applications (including back-end applications) a client secret is assigned during creation. The secret is only present in the response from the creation call.

Finally applications can be enabled, disabled and deleted. Disabled applications cannot be used to authenticate. The deletion process is a two-step sequence. The deletion endpoint disables and locks the application. This action can be reversed by using the /enable endpoint. If this is not done then at the scheduled time the application will be permanently deleted. After that point the action is irreversible.

Loading...