Yes, Ory Oathkeeper can be used to issue JWTs, which can help improve performance and reduce load on the database for session lookups. Oathkeeper provides an [ID Token Mutator](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token) that takes session information (for example, from Ory Kratos) and issues a signed JWT. This JWT can then be used by downstream services for authentication and authorization, eliminating the need to repeatedly call the session lookup endpoint (such as

/sessions/whoami

) for every request. This approach is particularly useful in high-traffic scenarios, as it offloads session validation from the database to stateless JWT verification, which is much faster and does not require a network roundtrip to the session store. The recommended setup is to use Oathkeeper as a reverse proxy in front of your application. Oathkeeper authenticates the session (e.g., using a session cookie and the

/sessions/whoami

endpoint), then issues a JWT using the ID Token Mutator. The protected application receives the JWT (typically in the

Authorization

header) instead of the session cookie, and can validate the JWT locally using the public key provided by Oathkeeper's JWKS endpoint. This reduces the number of session lookups and improves overall performance: > The [ID Token Mutator](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token) takes all the available session information and puts it into a JSON Web Token (JWT). The protected

SecureApp

will now receive

Authorization: bearer <jwt...>

in the HTTP Header instead of

Cookie: ory_kratos_session=...

. The JWT is signed using a RS256 key. To verify the JWT we can use the public key provided by Ory Oathkeeper's JWKS API. > ... > You could obviously also use other mutators such as the [Header Mutator](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#header) and use headers such as

X-User-ID

instead of the JWT. [Zero Trust with Access Proxy guide - Configuration](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#configuration) Additionally, the [Ory documentation on session management](https://www.ory.sh/docs/kratos/session-management/overview#json-web-token-jwt-support) recommends using session-to-JWT conversion to avoid repeated session lookups and improve performance: > If you don't want to make repeated calls to

toSession

/

/sessions/whoami

, or you need to use JWTs in your setup, you have several options: > - Recommended: Use [Session to JWT](https://www.ory.sh/docs/identities/session-to-jwt-cors). > - Alternative: Convert sessions to JWTs on your entry point. You then have the option to add caching to further reduce the number of API calls made. > ... > Ory Oathkeeper is an API Gateway capable of converting sessions to JWTs. [Session-management Overview](https://www.ory.sh/docs/kratos/session-management/overview#json-web-token-jwt-support) In summary, using Oathkeeper to issue JWTs is a recommended and supported way to improve performance and reduce database load for session validation in Ory-based architectures.

@chilly-king-10285 Does oathkeeper have some kind of caching for sessions or is this just shifting logic for converting sessions to JWT from backend/frontent to Oathkeeper?

Ory Oathkeeper itself does not provide built-in caching for session validation in the standard

cookie_session

authenticator. When using this authenticator, Oathkeeper calls the configured

check_session_url

(typically

/sessions/whoami

from Ory Kratos or Ory Network) for every request to validate the session cookie. This means that, by default, Oathkeeper is not caching session lookups and is simply shifting the logic for converting sessions to JWTs from your backend/frontend to the proxy layer. There is, however, community interest and discussion around adding caching to the

cookie_session

authenticator to reduce load on the session validation endpoint. For example, a [GitHub issue](https://github.com/ory/oathkeeper/issues/1167) describes the problem of hitting rate limits on

/sessions/whoami

due to lack of caching, and suggests adding an optional caching mechanism to the authenticator. As of the latest information in the knowledge sources, this feature is not yet available by default. Some mutators, such as the [

hydrator

](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#hydrator) and [

id_token

](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token-configuration), do support their own caching for the data they fetch or generate, but this is separate from session validation caching. In summary: Oathkeeper does not natively cache session lookups in the

cookie_session

authenticator; it primarily shifts the logic for converting sessions to JWTs to the proxy layer. If you need session caching, you should rely on Ory Network's Edge Sessions feature or implement caching at another layer until Oathkeeper adds this capability natively [Low latency with Edge Sessions](https://www.ory.sh/docs/concepts/cache), [Oathkeeper returns a 401 "Access credentials are invalid" when exceeding Ory Network's rate limiting on /sessions/whoami endpoint](https://github.com/ory/oathkeeper/issues/1167).

You're correct to question this—without caching, Oathkeeper itself does not inherently reduce the load on the session validation endpoint when using the

cookie_session

authenticator. Each request that requires session validation will result in a call to the configured

check_session_url

(such as

/sessions/whoami

). This means that, unless you implement caching elsewhere (for example, using Ory Network's Edge Sessions or a custom cache in your infrastructure), Oathkeeper is simply moving the session validation logic from your backend/frontend to the proxy layer, not reducing the number of lookups or the load on the session store. The main benefit Oathkeeper provides in this context is centralizing the logic for session validation and JWT issuance, which can simplify your architecture and make it easier to manage authentication and authorization. However, the actual reduction in load on the session store only happens if a caching layer is present—either in Ory Network (with Edge Sessions) or potentially in a future version of Oathkeeper if session caching is implemented. As of now, Oathkeeper does not natively cache session lookups in the

cookie_session

authenticator, and this has been identified as a limitation in community discussions and GitHub issues [Oathkeeper returns a 401 "Access credentials are invalid" when exceeding Ory Network's rate limiting on /sessions/whoami endpoint](https://github.com/ory/oathkeeper/issues/1167). So, to clarify: Oathkeeper does not reduce load on the session validation endpoint by itself unless caching is implemented elsewhere. Without caching, it simply centralizes the logic but does not decrease the number of session validation calls.