Ory Kratos session issuance: transition from legacy hooks to tokenized flows
0 reputation · 24 Dec 2022, 07:58 UTC
Session Issuance Logic in Kratos 1.x
Ory Kratos manages identity sessions through distinct mechanisms depending on the client type. While browser-based flows typically utilize HTTP-only cookies, native or API-driven clients require bearer tokens. This creates a compatibility boundary when migrating clients from legacy 0.x configurations to the stabilized 1.0 schema.
Configuration Constraints
The behavior of the self-service login flow is governed by the after hooks. Specifically, the session hook is responsible for the actual issuance of the session credential. If this hook is omitted or misconfigured during a version transition, the flow may report success without actually establishing a session.
There is an architectural uncertainty regarding the session validation strategy. Kratos provides opaque session tokens validated via the /sessions/whoami endpoint, but it does not natively mint OAuth2 access tokens.
- How does the
session_token_exchangeconfiguration affect the credential form returned to non-browser clients? - What is the recommended strategy for maintaining session persistence when transitioning from a legacy 0.x config to a 1.x environment?
