Short answer: usually yes for backend/API checks, not necessarily on every browser UI interaction. - Browser apps (React/Vue/SSR): You can call frontend.toSession() when you need to know whether the user is signed in (e.g., on page load, route guard, or before rendering protected content). The browser automatically sends the session cookie, and examples show checking once to guard views or middleware, not spamming every action. [[Session checks](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#session-checks); [React guide](https://www.ory.sh/docs/getting-started/integrate-auth/react#validate-and-login); [Vue guide](https://www.ory.sh/docs/getting-started/integrate-auth/vue#validate-and-login)] - Backend APIs: Each protected API request should validate the session sent by the client (cookie or token) by calling toSession (or /sessions/whoami). This is the reliable way to enforce auth per request on the server, since cookies aren’t implicitly trusted server-side. [[Check session status](https://www.ory.sh/docs/identities/sign-in/check-session-token-cookie-api); [Migrate: integrate backend](https://www.ory.sh/docs/migrate-to-ory#integrate-backend); [Identities session protect routes](https://www.ory.sh/docs/identities/get-started/session-management)] - Performance: Ory Network caches toSession/whoami globally, so per-request checks are fast. If you still want to reduce calls or need stateless tokens, use the Session to JWT feature. [[JWT support](https://www.ory.sh/docs/kratos/session-management/overview#json-web-token-jwt-support)] Practical guidance: - Frontend: check once per route/page load (or via middleware/guard) and reuse that state; refresh as needed (e.g., on 401). [[Session checks](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#session-checks); [Identities session protect routes](https://www.ory.sh/docs/identities/get-started/session-management)] - Backend: validate on every protected endpoint call by passing along cookies or the session token to toSession. [[Check session status](https://www.ory.sh/docs/identities/sign-in/check-session-token-cookie-api); [Migrate: integrate backend](https://www.ory.sh/docs/migrate-to-ory#integrate-backend)]

@chilly-king-10285 Can I reduce calls to session whoami unsung oath keeper ?

Yes—there are a few ways to reduce direct calls to /sessions/whoami, including with Oathkeeper, but there are trade-offs. Options: - Use Oathkeeper as the gate and avoid per-request whoami in your app: - Configure Oathkeeper’s cookie_session (or bearer_token) authenticator to call /sessions/whoami. Your upstream app then trusts Oathkeeper’s decision and does not need to call whoami itself on every request. This shifts the validation load from your app to Oathkeeper. [[Zero Trust guide](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#configuration); [WebSockets rules](https://www.ory.sh/docs/oathkeeper/guides/proxy-websockets#configure-ory-oathkeeper-and-ory-kratos)] - Caveat: Oathkeeper will still call whoami for its own checks. If you generate high request rates, you can hit Ory Network rate limits, and Oathkeeper can surface 401s when upstream whoami returns 429. [[Issue 1167](https://github.com/ory/oathkeeper/issues/1167)] - Add short-lived caching at Oathkeeper: - There’s an open request to add caching to cookie_session to mitigate bursts; currently, this is not built-in, so Oathkeeper may call whoami per request. [[Issue 1167](https://github.com/ory/oathkeeper/issues/1167)] - Workarounds today include reducing parallelism or using a different pattern below. - Use Session-to-JWT to reduce whoami calls: - Convert the session to a JWT via toSession with tokenize_as, then validate that JWT at your edge/app without calling whoami each time. This is explicitly recommended to reduce repeated calls. [[Session to JWT](https://www.ory.sh/docs/identities/session-to-jwt-cors); [JWT support](https://www.ory.sh/docs/kratos/session-management/overview#json-web-token-jwt-support)] - You can also have Oathkeeper convert sessions to JWTs using its mutators and then validate the JWT for subsequent requests, further cutting whoami traffic. [[JWT support](https://www.ory.sh/docs/kratos/session-management/overview#use-ory-oathkeeper-to-convert-sessions-to-jwts)] - Leverage Edge Sessions caching if you must call whoami: - Ory Network’s edge cache makes whoami fast and eventually consistent; you can tune cache TTL or force-refresh with Cache-Control headers when necessary. This doesn’t reduce calls, but it reduces latency and lets you balance freshness. [[Edge Sessions](https://www.ory.sh/docs/concepts/cache); [Force refresh](https://www.ory.sh/docs/concepts/cache#force-refresh)] - Backend pattern without Oathkeeper: - If your backend validates sessions itself, forward cookies to toSession per request (best practice), or use an in-memory cache with a short TTL to cut duplicate validations during bursts. This pattern is suggested as a workaround in rate-limit discussions. [[Integrate backend](https://www.ory.sh/docs/migrate-to-ory#integrate-backend); [[Issue 396](https://github.com/ory/network/issues/396)] In short: Oathkeeper can help you avoid calling whoami from your app, but without additional caching it will still call whoami per request. To truly reduce calls, use Session-to-JWT (via Ory or via Oathkeeper’s JWT mutator), or introduce brief caching at the proxy layer. [[Issue 1167](https://github.com/ory/oathkeeper/issues/1167); [Session to JWT](https://www.ory.sh/docs/identities/session-to-jwt-cors)]