OKTA

Okta integrates with CCaaS as a SAML 2.0 or OIDC identity provider, requiring coordinated setup between the customer's Okta tenant and Xima Software.

Okta connects to CCaaS as an identity provider (IdP) for Single Sign-On, enabling centralized user management alongside secure authentication. Unlike the Microsoft and Google SSO connections configured directly in CCaaS, an Okta integration is a coordinated setup between the customer's Okta tenant and Xima Software, using either SAML 2.0 or OIDC.

Prerequisites

Before beginning the integration, the following must be in place:

Administrative access within the customer's own Okta tenant
Agreement on which authentication protocol — SAML 2.0 or OIDC — aligns with the organization's internal security policies

⚠️
Customer-Managed Solution
The customer's Okta environment is configured and maintained by the customer. Xima cannot access or manage the Okta instance.

Choosing an Authentication Protocol

Two authentication protocols are supported, each with a different exchange of configuration values between Xima Software and the customer.

SAML 2.0

SAML 2.0 is the recommended protocol for strict corporate environments and systems requiring XML-based assertions.

Item Name	Provided By	Description
ACS URL	Xima Software	The Assertion Consumer Service URL — the endpoint where Xima receives the XML POST from Okta.
SP Entity ID	Xima Software	The unique identifier for the application, often the base URL or ACS URL.
NameID Format	Xima Software	The expected username format, standardized as `EmailAddress`.
IdP SSO URL	Customer	The specific Okta URL where the application redirects users for login.
IdP Issuer ID	Customer	The unique entity ID for the organization's Okta instance.
X.509 Certificate	Customer	The public key certificate used to verify that the XML response is authentic.

✅
Pro Tip
Configuration efficiency can be improved by generating a Metadata XML file from the Xima application and importing it directly into Okta to auto-populate these fields.

OIDC / OAuth

OpenID Connect (OIDC) is the modern standard, suited to web-based applications and mobile platforms.

Item Name	Provided By	Description
Redirect URI	Xima Software	The exact URL where Okta sends the user after a successful authentication.
Logout Redirect URI	Xima Software	Optional — the destination for the user after logging out.
Client ID	Customer	The public identifier for the application within the Okta system.
Client Secret	Customer	A private security key. Must be treated as a sensitive credential.
Issuer URL	Customer	The base URL for the OIDC authorization server, e.g. `https://company.okta.com`.

✅
Pro Tip
Once the Issuer URL is established, additional configuration details — endpoints, scopes, and keys — can be located by appending /.well-known/openid-configuration to the URL.

Integration Workflow

Each protocol follows its own sequence of steps split between Xima Software and the customer.

SAML 2.0 Integration Sequence

Provisioning (Xima): Xima Software provides the Service Provider (SP) Metadata — ACS URL and Entity ID — to the customer
App Creation (Customer): The customer creates a new SAML 2.0 App Integration within their Okta Admin Console using Xima's metadata
Handshake (Customer): The customer exports the Identity Provider (IdP) Metadata — or the SSO URL, Issuer ID, and X.509 Certificate — and sends it to Xima Software
Finalization (Xima): Xima Software uploads the customer's IdP metadata into the application backend to complete the link
Validation (Joint): Both parties verify a successful login using a test user account

OIDC / OAuth Integration Sequence

Provisioning (Xima): Xima Software provides the Login Redirect URI to the customer
App Creation (Customer): The customer creates an OIDC - Web Application integration in their Okta Admin Console
Handshake (Customer): The customer copies the Client ID, Client Secret, and Issuer URL and securely provides them to Xima Software
Finalization (Xima): Xima Software configures the OIDC client settings in the application environment using the customer's credentials
Validation (Joint): Both parties verify that the application correctly redirects to Okta and returns a valid token

Updated about 3 hours ago