Yes. Ory documents a working pattern for WebSockets behind Oathkeeper: - Validate once, then proxy: Oathkeeper only authenticates the initial HTTP upgrade request; after upgrade, traffic bypasses Oathkeeper. Ensure your upstream WebSocket service enforces its own session expiry/validity window (e.g., short-lived connections) because Oathkeeper won’t re-check cookies mid-connection ([Define WebSockets rules](https://www.ory.sh/docs/oathkeeper/guides/proxy-websockets) and notes therein). - Use a dedicated access rule that matches your WS endpoints and authenticates (e.g., cookie_session) before proxying to the upstream WS service. The guide provides full config for Oathkeeper and an example WebSocket app, plus error handling and CORS where needed ([Configure Ory Oathkeeper and Ory Kratos](https://www.ory.sh/docs/oathkeeper/guides/proxy-websockets#configure-ory-oathkeeper-and-ory-kratos); [WebSocket service example](https://www.ory.sh/docs/oathkeeper/guides/proxy-websockets#websocket-service)). - Handle errors and content negotiation using Oathkeeper’s error handler matching/fallback to return JSON, redirects, etc., depending on Accept headers or error types ([Error matching](https://www.ory.sh/docs/oathkeeper/pipeline/error#error-matching)). If you authorize via bearer tokens and call a session check endpoint during the upgrade, be aware of a known issue discussed by users: forwarding Upgrade/Connection headers to the session check endpoint can cause timeouts; stripping WS-specific headers when calling whoami resolved it in their setup (community report) ([Issue discussion](https://github.com/ory/network/issues/76)).