Question
Ory Kratos session expiry and Oathkeeper access enforcement for expired credentials
Zo Echo
0 reputation · 31 Jul 2020, 07:10 UTC
20.9K views
Loading…
0 reputation · 31 Jul 2020, 07:10 UTC
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?
35275 reputation · 31 Jul 2020, 13:33 UTC
Oathkeeper does not query Kratos session state on every request by default. It enforces access based on the presented credential and its configured access strategy. For JWTs, Oathkeeper validates the signature and the exp claim using its own clock; it does not call Kratos to confirm that the underlying session is still valid. For opaque tokens, Oathkeeper contacts Kratos only if the introspection strategy is explicitly enabled. When a Kratos session TTL expires but the presented credential remains valid under Oathkeeper's own checks, Oathkeeper can continue to allow the request. Oathkeeper is the authoritative enforcement point for each request it receives; Kratos governs session lifecycle but does not revoke Oathkeeper's decision unless introspection is configured and consulted.
Confirmed: Oathkeeper access decisions are driven by its configured strategy, not by an automatic Kratos session lookup. A JWT with a future exp is accepted even if Kratos has invalidated the session, because Oathkeeper has no session revocation feed unless introspection is enabled.
Likely explanation: Continued access after session expiry usually indicates a mismatch between Kratos server-side invalidation and Oathkeeper credential-only validation. Clock skew between Kratos and Oathkeeper can also cause a token to appear valid on one side and expired on the other.
oryexp passes, independent of Kratos session TTL.# Check Oathkeeper access logs for the strategy field, for example: # "strategy": "jwt" or "strategy": "opaque"
For JWTs, issue a token with a future exp, invalidate the Kratos session, then send a request through Oathkeeper. A 200 response means Oathkeeper is relying on the credential alone. For opaque tokens, call Kratos introspection directly after invalidation and confirm "active": false, then verify that Oathkeeper rejects the request.
Missing diagnostic detail: Which access strategy and token type is Oathkeeper currently using? This determines whether introspection is already active or must be added.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 31 Jul 2020, 17:37 UTC
The authority question resolves by authenticator, not by product: Oathkeeper keeps no session store of its own.
jwt authenticator, validation is purely local — signature, exp, iss, aud. Server-side Kratos expiry or revocation is invisible; the token passes until its own exp, independent of session state.cookie_session or header_session pointed at Kratos' /sessions/whoami, Oathkeeper asks Kratos per request, making Kratos authoritative — this also catches logout revocation, not just TTL expiry. Kratos session tokens are opaque, so whoami is the native integration path; oauth2_introspection instead targets RFC 7662 endpoints such as Hydra's.Two caveats: response caching reopens a window equal to the cache TTL, so keep it under the session lifespan, and clock skew shifts JWT expiry decisions either way. Assuming Kratos 1.x and a recent Oathkeeper, verify the caching knobs against your installed version — a quick test is revoking a session via the logout API, then replaying the token under both configurations.