# Managing session lifecycles with Ory > Design session creation, validation, expiration, renewal, reauthentication, and revocation with Ory examples—and keep OAuth tokens on a separate lifecycle. Canonical URL: https://www.devobs.io/articles/managing-session-lifecycles/ By: Lena Fischer Published: 2026-10-11T09:30:58.590Z Updated: 2026-10-11T09:30:58.590Z Section: Identity Manage authenticated sessions through explicit lifecycle rules: create them after authentication, validate them before protected work, expire them on a defined schedule, renew them under a bounded policy, require fresh authentication for sensitive actions, and revoke them when access should end. Keep identity-session policies separate from OAuth token policies. Protect the session, not just the login flow. OWASP recommends HTTPS for the entire web session, rather than only during authentication, and the `Secure` cookie attribute to restrict transmission of session cookies to encrypted connections. [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) ## Create the right session for the client Ory's session overview distinguishes browser flows, which issue an Ory Session Cookie, from non-browser flows, which issue an Ory Session Token—for example, to a native mobile application. Ory requires isolation between cookies and session tokens. [Ory session overview](https://www.ory.com/docs/kratos/session-management/overview) Choose the supported integration path before implementing credential handling. Do not design a browser application around the native session-token flow simply to make client code look uniform. For each client, write down: - Which authentication flow establishes the session. - Which session credential the client receives. - Which component resolves that credential into session state. - What the client should do when the session is no longer accepted. This contract gives the login screen, backend, and client application the same lifecycle to implement. ## Validate session state before protected work A session credential should lead to a decision about session state—not merely a check that the client supplied something. For browser-cookie sessions, Ory documents `/sessions/whoami` as the endpoint for retrieving the session payload. Its session model includes three useful properties: | Property | Documented meaning | | --- | --- | | `active` | When true, the session is active and can authenticate requests. | | `expires_at` | The time at which the session expires, based on the configured lifespan. | | `authenticated_at` | The time of the most recent successful authentication. | Ory documents updates to `authenticated_at` when the user authenticates with a second factor or successfully reauthenticates through a login flow using `refresh=true`. [Ory session overview](https://www.ory.com/docs/kratos/session-management/overview) Keep three decisions separate in request handling: whether the session is accepted, whether the operation requires more recent authentication, and whether the user is authorized to perform the operation. Do not make a client-supplied timestamp the authority for those decisions. Specify failure behavior as well. For protected operations, stop when authentication cannot be established rather than silently continuing as though validation succeeded. Test an expired session separately from an unavailable session service so that operational failures do not get confused with normal sign-in requirements. ## Define expiration and renewal as separate policies Ory exposes session lifespan through `session.lifespan`, expressed using hours, minutes, and seconds. Its documentation states that users must reauthenticate when the lifespan expires. The documented `720h` example represents 30 days; it is an example configuration, not a recommended duration for every application. [Ory session lifespan](https://www.ory.com/docs/kratos/session-management/session-lifespan) Renewal changes the expiration calculation. Ory documents a refreshed expiration as the refresh time plus the configured session lifespan. It also provides an administrative session-extension API. [Ory session refresh](https://www.ory.com/docs/kratos/session-management/refresh-extend-sessions) For example, with an illustrative eight-hour lifespan, an accepted refresh at 15:00 moves expiration to 23:00. That is different from an absolute deadline eight hours after the original login. Before implementing renewal, decide: - **Trigger:** Does renewal follow user activity, reauthentication, or an administrative action? - **Eligibility:** How close to expiration must a session be before extension is allowed? - **Maximum age:** Should a separate policy limit how long renewal can postpone a new login? - **Inactivity:** If an idle timeout is required, what activity counts, and which component enforces it? Specify maximum-age and inactivity requirements separately from the nominal lifespan. Do not assume one duration setting implements every timeout policy. Ory documents `session.earliest_possible_extend` as a refresh threshold. A value of `24h`, for example, prevents refresh earlier than 24 hours before expiration. Setting the threshold equal to the lifespan permits refresh throughout the session's lifetime; Ory warns that this results in constant refreshes. Choose the window deliberately rather than maximizing renewal eligibility by default. [Ory session refresh](https://www.ory.com/docs/kratos/session-management/refresh-extend-sessions) ## Require recent authentication for sensitive changes Session expiration and authentication freshness answer different questions: how long the session may remain usable, and how recently the user authenticated. For certain profile changes—including email address changes, password changes, and adding or removing two-factor authentication—Ory requires a privileged session. The documented condition is that the age of `authenticated_at` is less than `privileged_session_max_age`. [Ory session lifespan](https://www.ory.com/docs/kratos/session-management/session-lifespan) To prompt reauthentication, Ory supports browser and API login flows with `refresh=true`. To also require refreshing the second authentication factor, the documented parameters are `refresh=true` and `aal=aal2`. Successful reauthentication updates `authenticated_at`; merely starting the flow is not the documented authentication event. [Ory session refresh](https://www.ory.com/docs/kratos/session-management/refresh-extend-sessions) Apply the same distinction to sensitive application operations. Require evidence of recent authentication where appropriate; do not treat a later expiration timestamp alone as proof that the user just authenticated. Treat checks on your own application endpoints as an explicit implementation responsibility rather than assuming Ory's account-settings checks cover them. ## Give logout and revocation a precise scope Ory lists lifespan, refresh, and revocation among its session-management controls. [Ory Kratos introduction](https://www.ory.com/docs/network/kratos/intro) Turn those capabilities into explicit product behavior. Define separate contracts for actions such as: - **Sign out here:** End the current session. - **Sign out other sessions:** End the specified set of other sessions. - **Respond to account compromise:** End the sessions and credentials included in the incident-response policy. These are proposed application contracts, not claims that every Ory logout operation implements all three scopes. For each action, identify the server-side invalidation operation and the client-side cleanup that follows it. Do not define success solely as hiding authenticated UI or removing a local credential. In a controlled integration test, retain the old credential and check whether a protected request is rejected after the intended invalidation completes. Make account-event policies explicit too. Decide what password changes, account recovery, and administrative account actions should do to existing sessions, then test those outcomes rather than assuming automatic revocation. ## Keep OAuth tokens on their own lifecycle Ory Network's OAuth 2.0 and OpenID Connect service is built on Ory Hydra. Ory documents that the service is connected to Ory Identities by default, while its headless API also supports integration with another user-management system. [Ory Hydra introduction](https://www.ory.com/docs/network/hydra) Model identity sessions and OAuth tokens separately. For each artifact, record its issuer, expiration policy, renewal mechanism, and revocation operation. Treat cross-system logout as an explicit integration requirement, not an assumed consequence of connecting the services. RFC 7009 defines an OAuth endpoint through which a client can request revocation of a previously obtained refresh or access token. A revocation request invalidates that token and, where applicable, other tokens associated with the same authorization grant. Do not interpret that grant-level relationship as a promise that ending an identity session also revokes its user's OAuth tokens. Define and test that integration separately. [RFC 7009](https://www.rfc-editor.org/rfc/rfc7009) The RFC's implementation note also explains why resource-server behavior matters: self-contained access tokens can be evaluated without contacting their issuer. It identifies backend interaction between the authorization server and resource server as one approach to immediate revocation of those tokens. Test enforcement at the protected resource, not just the response from a revocation endpoint. [RFC 7009](https://www.rfc-editor.org/rfc/rfc7009) Before describing a feature as “sign out everywhere,” test both identity-session access and the OAuth tokens covered by that promise. ## Test transitions, not just successful login Build lifecycle tests around observable outcomes: 1. Authenticate through each supported client flow and confirm the expected session mechanism. 2. Present an expired session to a protected operation and verify rejection. Separately test failure of the validation service. 3. Attempt extension before and within the configured renewal window. 4. Confirm that successful reauthentication updates authentication freshness. 5. Attempt a sensitive operation with an active session that does not meet the required freshness policy. 6. Revoke the intended session scope and retry with the affected credentials. 7. Check OAuth token behavior independently after identity-session logout, including access at the resource server. The goal is a lifecycle contract that remains clear beyond the happy path: what establishes access, what preserves it, what requires the user to authenticate again, and what reliably ends it. ## Source references - - - - - - -