Okta Prompts for MFA During Veeva Vault eSignature Pop-Up Authentication

Okta prompts for Multi-Factor Authentication (MFA) during a Veeva Vault eSignature pop-up authentication instead of honoring the password-only application sign-in policy. This occurs due to a session domain mismatch between the main window and the pop-up. Resolving the domain mismatch ensures Okta reuses the session and honors the application sign-in policy.

When integrating Okta Identity Engine (OIE) with Veeva Vault eSignature using service provider (SP) initiated Security Assertion Markup Language (SAML), Veeva launches the identity provider (IdP) flow in a browser pop-up. Okta treats the pop-up as a new session and re-applies the Global Session Policy MFA requirement before evaluating the application sign-in policy.

• Okta Identity Engine (OIE)
• Veeva Vault eSignature
• Service Provider (SP) Initiated SAML
• Custom Domains

A session domain mismatch between the main window and the pop-up causes the issue. When authentication occurs through a custom domain (for example, login.company.com) in the main window, and Veeva launches an IdP-initiated SAML flow in a pop-up, the pop-up might authenticate against a session from the Okta default domain (for example, company.okta.com). Because these are separate domains, the browser does not reliably reuse the session cookies from the main window in the pop-up context. Okta treats the pop-up as a new session and evaluates the Global Session Policy first, which requires MFA. Okta evaluates the application sign-in policy (password-only) only after satisfying the Global Session Policy requirement.

How is the session domain mismatch resolved?

Verify the domain configuration and check the Okta System Log to ensure Okta evaluates the correct policy.

1. Verify the domain configuration. Confirm whether the main window authenticates through a custom domain and whether the pop-up directs to the default Okta domain. Both flows must use the same domain to ensure session reuse.
2. Check the Okta System Log to confirm which policy Okta evaluates during the pop-up authentication. Filter the logs using the following query to view the exact policy path taken:

   eventType eq "policy.evaluate_sign_on"

3. Contact Okta Support for further assistance if both flows use the same domain and the issue persists.

NOTE: In Okta OIE, the Global Session Policy and application sign-in policies work together, but Okta evaluates the Global Session Policy first during the initial authentication handshake. Okta evaluates the application sign-in policy after satisfying the Global Session Policy requirements. This is by design, and administrators cannot reverse this behavior through configuration. If both the main window and pop-up use the same domain and session context, Okta reuses the existing session and honors the application sign-in policy password-only rule on the second authentication attempt.