Okta Verify fails to prompt for authentication on corporate networks due to enterprise security controls interfering with local loopback or outbound HTTPS traffic. Resolve this issue by bypassing Okta domains from Secure Sockets Layer (SSL) inspection, correcting proxy configurations, and ensuring firewalls allow WebSockets and local port communication. When accessing an Okta Single Sign-On (SSO) integrated application on a corporate network, the Okta Verify window does not prompt the user to authenticate. Manually opening the Okta Verify application requires multiple attempts before it becomes responsive and allows access. This issue does not occur on external networks, such as home Wi-Fi or public hotspots.

• Okta Identity Engine (OIE)
• Okta Verify
• Okta FastPass
• Windows

Corporate network security controls interfere with the local loopback communication or outbound HTTPS traffic required by Okta Verify. Common causes include SSL or Transport Layer Security (TLS) inspection proxies intercepting traffic, Proxy Auto-Configuration (PAC) files routing localhost traffic to the proxy, firewalls terminating WebSocket connections, or endpoint security agents blocking local ports when the device connects to a corporate domain profile.

What is the Okta Verify desktop authentication flow?

Understand the Okta Verify desktop authentication flow by reviewing the following sequence of browser, application, and network interactions.

1. The user navigates to the application in the browser.
2. The application redirects the browser to the Okta tenant URL.
3. The Okta sign-in widget loads in the browser and executes a JavaScript probe to communicate with the local Okta Verify service over the local loopback address (127.0.0.1 or localhost) on specific Transmission Control Protocol (TCP) ports that the operating system assigns dynamically, or via a custom Uniform Resource Identifier (URI) protocol handler (okta-verify://).
4. The Okta Verify Windows application contacts the Okta Identity Engine over port 443 (HTTPS) to request the specific authentication challenge for the session.
5. The Okta Verify window prompts the user for interaction.
6. The application uses cryptographic keys located securely on the Windows device to sign the challenge.
7. Okta Verify sends the cryptographically signed response back to Okta over port 443.
8. Okta validates the signature and signals the local Okta Verify application that authentication is successful.
9. The desktop application passes a session token back to the browser via the local loopback connection.
10. The browser passes the token to the application to complete the login process.

How is the Okta Verify prompt failure resolved for authentication on corporate networks?

Resolve the authentication prompt failures by investigating and adjusting the following corporate network and security configurations.

• SSL/TLS Inspection: Ensure all Okta domains bypass SSL inspection and decryption. Okta Verify uses strict certificate pinning and mutual TLS. If a corporate proxy intercepts the traffic from the Okta Verify desktop application to *.okta.com, the application rejects the proxy certificate and causes the prompt to hang or fail.
• Proxy PAC File Misconfiguration: Ensure the proxy rules explicitly bypass localhost and loopback addresses. If a PAC file routes localhost or 127.0.0.1 traffic to the corporate proxy, the browser fails to wake up the Okta Verify application.
• WebSocket and Long-Polling Interference: Ensure corporate firewalls allow persistent connections. Communication between the browser, Okta Verify, and Okta relies on WebSockets or long-polling. Firewalls that terminate idle connections or block WebSockets break the authentication flow.
• Endpoint Security: Ensure Windows Firewall or Endpoint Detection and Response (EDR) agents allow local port communication on the corporate domain profile. Stricter local port-blocking rules prevent Okta Verify from communicating with the browser.
• Browser "Local Network Access" (LNA) Policies: Ensure users select Allow when the browser prompts for "[subdomain].okta.com to look for and connect to any device on your local network". Alternatively, suppress this prompt for devices via the steps outlined in the Configure Chrome to Suppress the Local Network Access Prompt for Okta FastPass documentation.