Ory Kratos session expiry and Oathkeeper access enforcement for expired credentials

Ory Kratos session expiry and Oathkeeper access enforcement for expired credentials

Goal: determine whether an expired Ory Kratos authentication session causes Oathkeeper to reject subsequent requests at the access proxy, or whether Oathkeeper continues to allow access based on its own token validation until the credential or token independently expires.

Kratos invalidates sessions server-side after the configured TTL, while Oathkeeper evaluates access strategies such as JWT validation or opaque token introspection using its own clock and configuration. The interaction is version-sensitive and depends on token format, introspection settings, caching, and clock skew between components. Behavior may also differ between Ory Network and self-hosted distributions. Authentication alone does not provide least-privilege enforcement; an authorization layer such as Ory Keto or Oathkeeper access rules is assumed separately.

Does Oathkeeper query Kratos session state on each request, or does it rely solely on the presented credential? Which component is authoritative for rejecting an expired credential when Kratos session TTL and Oathkeeper token lifetime are misaligned?