Federated authentication.

Verint Connect — Thu, 02 Apr 2026 15:52:30 GMT

Current Revision posted to Verint Identity by Verint Connect on 4/2/2026 3:52:30 PM

With federated user authentication, your Identity Provider (IdP) authenticates users in your company or organization. When a user signs in to a Verint Identity-enabled product, the IdP vouches for the identity of the user. Verint Identity-enabled products are Verint applications and services that support Single Sign-On (SSO) through Verint Identity.

Identity V2 and Identity V1

With Verint Identity, a federated authentication flow involves the user who wants to access a Verint Identity-enabled product, the Verint Identity Service, the identity platform used by Verint, and your IdP.

Identity V2 and Identity V1 are Verint Identity options based on different identity platforms used by Verint.

Identity V2

Identity V2 uses an industry-standard identity platform which supports OpenID Connect (OIDC) and SAML (Security Assertion Markup Language) 2.0 for exchanging authentication information. Identity V2 supersedes Identity V1 and provides the platform for new configurations.

Identity V1

Identity V1 uses Microsoft Entra ID as its identity platform. If Microsoft Entra ID is the primary IdP for your company or organization, Verint supports Microsoft Entra ID business to business (B2B) collaboration to exchange authentication information. Identity V1 also supports SAML 2.0 for non-Entra ID IdPs.

If Microsoft Entra ID is the primary IdP for your company or organization, direct SAML 2.0 integration requires Identity V2.

OpenID Connect

OIDC is an open authentication standard that uses JSON Web Tokens (JWTs) for transmitting user authentication information. The tokens include details about users and their authentication status. OIDC also enhances the standardization of scopes and claims, making it easier for different systems to communicate with each other.

Typically, the OIDC flow for user authentication is:

A user accesses a Verint application or service.
The Verint Identity Service sends an OIDC authentication request to the customer IdP.
The IdP validates the credentials for the user and obtains authorization.
The IdP issues an identity (JWT) token and sends it to the Verint Identity platform.
The Verint application grants the user access.

OIDC is supported by Identity V2 only.

SAML 2.0

SAML 2.0 is an open standard for the exchange of authentication information using security assertions, which are XML-based statements that contain information about a user’s identity, attributes, and authentication status. Both Identity V2 and Identity V1 support SAML 2.0.

SAML 2.0 certificates

A SAML 2.0 trust relationship involves a signing certificate used to ensure that authentication requests and responses are genuine. Certificates consist of a private key and public key (a key pair). When the IdP sends a SAML assertion, it is signed with the private key and, to verify the signature when it receives the SAML assertion, Verint requires the public key. With SAML, the private key is referred to as the signing certificate and the public key is referred to as the verification certificate.

Signing certificates have a scheduled expiration date. Typically, if the signing certificate passes its scheduled expiration date, single sign-on (SSO) fails and your company will need to renew or replace the certificate.

SP-initiated authentication flow

With SAML 2.0, SP-initiated flows are the default authentication flow between Verint Identity and your IdP. An SP-initiated authentication flow starts with Verint as Service Provider (SP). Users sign in to a Verint application or service, the Verint Identity Service redirects the request to the IdP for authentication, and, if authentication is successful, the Identity Service grants the user access to the application. Both Identity V2 and Identity V1 support SP-initiated flows with SAML 2.0.

When a user starts a new session, the SP-initiated flow requires the user to sign in to authenticate with the IdP. The authentication flow is seamless:

The user wants to access a licensed Verint application or service.
The Verint Identity Service redirects the user access request to the IdP.
The IdP authenticates the user, and redirects the request back to the Verint Identity Service.
The Verint Identity Service verifies that the user has permission to access the application and grants the user access.
The user is signed in to the application or service.

If the user has an active session with the IdP, the user does not need to reenter their credentials when they request access to the Verint application or service.

IdP-initiated authentication flow

With an IdP-initiated flow, a user signs in to your company IdP portal and selects the Verint application or service they want to access. The IdP authenticates the user and redirects the user request to the Identity Service which grants access to the required application.

Identity V2 supports IdP-initiated authentication flows for access to Workforce Engagement (WFE) and Data Insights Bot only. Idp-initiated flows are not supported by Identity V1.

For an IdP-initiated flow, Verint Identity requires you to identify the Verint application or service to which your Idp sends users. When a user requests access to that application or service, your IdP initiates the flow for sign-in.

For each Verint product or service, Verint Identity requires a separate SAML 2.0 federation. Each federation requires its own signing certificate.

Microsoft Entra ID B2B collaboration

If Microsoft Entra ID is the primary IdP for your company or organization, or if your primary IdP uses a domain name verified in Entra ID, you can set up Microsoft Entra ID B2B collaboration with Identity V1 to exchange user authentication information.

With B2B collaboration, if your Microsoft Entra tenant forwards authentication requests to another IdP (such as Okta), Microsoft automatically passes authentication requests from Verint Identity to the IdP.

Entra ID B2B collaboration is available with Identity V1 only.