Specific requests to an OAG application are failing or not functioning as expected. When reviewing the associated calls from Network tab in browser developer tools, some signature observations are:

• The call that is failing shows a request URL that starts with "wss://"
• The call that is failing includes the following Request Headers:
  • Connection: Upgrade
  • Upgrade: websocket
• The issue may not occur when bypassing OAG.
• The nature of the failure may vary depending on how the application handles these calls. Some applications may terminate the connection with OAG upon receiving this request, others may respond with a 503. Therefore there is not a telltale signature for this exact issue in OAG logs.

• Okta Access Gateway (OAG)
• Okta Identity Engine (OIE)
• Okta Classic Engine

The request is attempting to switch protocol to WebSockets by using the "Connection: Upgrade" and "Upgrade: websocket" headers. However, by nature of the specification of these headers as "hop-by-hop" headers, by default, OAG as the reverse proxy will not pass these request headers to the Protected Resource.

More details about WebSocket proxying via NGINX are available on the WebSocket proxying documentation.

For all paths in the application that will require upgrading to WebSocket protocol, add custom configuration to a policy with the following:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

This will allow OAG to relay the Upgrade/Connection headers to the Protected Resource and should allow the call to succeed, barring any other issues or application-specific behavior.

Related References

More details on configuring OAG with WebSocket applications are available in the following documentation:

• Add a Websocket-based application  
• Add required access policy