Will Your Self-Hosted App Sessions Expire When They Should? A Practical Evaluation Checklist

Why session behavior matters after sign-in

Authentication establishes that a user has signed in. A session is what lets the application recognize that user as they move between pages or return to the app. If a session remains usable longer than intended, someone with access to the browser or a copied session credential may be able to continue using the account.

A configured timeout is not proof that every relevant path expires as expected. Sign-out, a password change, account deactivation, and single sign-on can involve different parts of the system. Treat session behavior as a lifecycle to evaluate and retest, not a single setting to locate.

OWASP advises enforcing session expiration on the server and invalidating a session when the user logs out. NIST says session cookies should expire at or soon after the session’s validity period. These are useful checks, but they do not establish that every application provides the same controls or that every workflow has a universal required outcome.

Separate sign-in, session lifetime, idle timeout, and remembered devices

Before reviewing settings, use consistent terms. Sign-in is the authentication step. A session is the application’s continuing recognition of that sign-in. The session may be represented or maintained through more than one mechanism, so a browser cookie’s displayed expiry alone may not tell you whether the server still accepts the session.

An idle timeout limits a session after a period without activity. A maximum session age, sometimes called an absolute lifetime, limits how long a session can remain valid regardless of activity. Do not assume that activity resets an absolute limit, or that a setting called “session timeout” means one specific thing; check the application’s documentation and test its behavior.

A “remember me” or remembered-device option may change what the user experiences at a later visit. Find out whether it restores a session, avoids some authentication steps, or does something else in that particular application. Record its behavior separately rather than treating it as the same control as an idle timeout.

Set requirements around real workflows and risk

Choose requirements based on how the application is used and what an unattended or still-valid session could expose. A shared workstation, access to sensitive business records, or the ability to make consequential changes may call for different expectations from an app used briefly on a private device.

Write down the expected behavior before testing. For example, decide what your organization expects after inactivity, at a maximum session age, after explicit sign-out, and after an administrator disables an account. For password changes and SSO events, define the outcome you need rather than assuming the application or identity provider will handle it automatically.

There is no single timeout value established by the guidance cited here for every application and workflow. Make the decision an explicit security and usability choice, and document any exception, such as a workflow where users need to keep a session open for a long-running task.

• Which data or actions are available in the app, and what could an unattended session permit?
• Are users likely to work on shared or unattended devices?
• What should happen after inactivity, and what is the longest acceptable session age?
• Which events should end access: sign-out, password change, account deactivation, or an identity-provider change?
• Does a remembered-device option exist, and is its behavior acceptable for your use case?

Read the application documentation for actual controls

Search the official documentation for session expiration, idle timeout, maximum lifetime, logout, session revocation, remembered devices, and SSO. Check the documentation for the application and version you operate. Do not infer a feature from a similarly named product or from a setting in another app.

Record whether each control is configurable, where it is configured, and whether the documentation describes server-side enforcement. If the documentation is silent about a workflow, mark it as unknown and test it or ask the vendor or maintainer. A cookie expiration setting and a server-side session validity rule are related checks, but one should not be treated as proof of the other.

OWASP’s guidance supports checking server-side expiration and invalidation on logout. NIST’s guidance supports checking that session cookies expire at or soon after the session validity period. Neither cited excerpt specifies the behavior you should expect for password changes, account deactivation, maximum age, or identity-provider sessions; verify those cases for your app.

• Record the documented meaning of each timeout setting, including whether activity resets it.
• Look for a documented way to end or revoke active sessions, and note its scope.
• Check whether session behavior differs for local accounts and SSO users.
• Keep a record of the documentation title, version or date where available, and the date you reviewed it.

Run practical lifecycle tests

Use a test account and a non-production environment where possible. If you need to test in production, plan the work to avoid disrupting other users or changing real account access unexpectedly. Keep the test account’s data non-sensitive and avoid putting session credentials or other secrets into screenshots or shared notes.

For inactivity, sign in, leave the app unused for the configured interval, and then try to open a protected page or perform a harmless action. Test an active session against the maximum-age expectation separately: keep the session active as required by your test plan and see whether it ends at the stated limit. Record elapsed time and what the user sees.

For sign-out, log out and then try to revisit a protected page using the same browser context. OWASP advises that logout invalidate the session; record whether the old session can still access protected content. Do not treat a redirect to a login page alone as conclusive if protected content remains accessible through another route.

Test password change and account deactivation as separate events. For each, determine whether existing sessions continue to work, whether the change affects only future sign-ins, and whether the behavior matches your written requirement. The supplied primary guidance does not establish a universal required outcome for these cases, so document your policy and verify the application’s behavior rather than assuming.

Use a harmless, authorized test action to confirm access status. If the outcome is unclear, repeat the test in a clean browser session and consult the application’s documentation or support channel.

Repeat the checks for SSO and local accounts

Where the application supports both local sign-in and single sign-on, test each path separately. The application and identity provider may have separate sessions; ending one does not, by itself, prove the other has ended. Likewise, signing out of an application does not necessarily sign the user out of the identity provider.

For SSO, record the sequence and result for application sign-out, identity-provider sign-out, password changes, and account deactivation. Verify what happens when the user returns to the app and when they try to use an already-open app page. For local accounts, repeat the relevant tests without assuming the SSO behavior applies.

If the identity provider or application offers session revocation controls, document what they claim to revoke and confirm the effect in a test. If the system’s behavior is not documented or testable, keep that as an unresolved gap rather than interpreting an apparently successful redirect as proof.

Record expected behavior and evidence in a session test matrix

A compact matrix turns one-off checks into repeatable operational evidence. Keep the expected result separate from the observed result: the first reflects your policy, while the second reflects what the app did during the test.

Include the app and version, authentication path, test date, relevant configuration, test account, steps, elapsed time where relevant, observed result, and pass, fail, or unresolved status. Note any documentation consulted and the next action for gaps. Avoid recording passwords, session tokens, or other credentials.

Repeat the matrix after material changes to application configuration, authentication setup, or deployment. The schedule is an operational choice for your team; the sources cited here do not prescribe a retest interval.

• Inactivity: expected end condition; idle interval tested; whether protected access remained available.
• Maximum session age: expected limit; whether the session stayed active during the test; observed end time and result.
• Sign-out: expected invalidation; result when reusing the same browser context.
• Password change: expected impact on existing sessions; result for the account being tested.
• Account deactivation: expected impact; result for existing and new access attempts.
• SSO and local sign-in: test each applicable path and record which system’s session was involved.
• Gaps: undocumented controls, results that could not be verified, and an owner for follow-up.

Assign responsibilities across the application, identity provider, and hosting

Do not assume that one party controls the entire session lifecycle. Map each expected behavior to the component that can configure or verify it in your deployment. The precise allocation depends on the application, identity provider, hosting arrangement, and agreements in place; the cited guidance does not assign responsibilities among them.

The application owner should document the access policy, verify application behavior, and decide how to handle unresolved gaps. For SSO workflows, coordinate with the identity-provider administrator to understand its session and account controls, then test the combined experience. Make the division of duties explicit instead of relying on a general assumption that SSO or hosting handles revocation.

Hosting responsibilities should also be stated clearly. Airbip offers managed deployment of catalog applications as Docker workloads on Airbip cloud servers, with automated routing and TLS certificates through Traefik and Let’s Encrypt, plus service lifecycle management and configurable backups. These infrastructure capabilities do not, on their own, establish what an application does when a session expires or an account is disabled. Confirm the application-level behavior and agree who handles each operational task.

If your organization needs a session control that the application does not provide, do not treat infrastructure management as a substitute unless a documented and tested control meets the requirement. Record the gap and decide whether to change configuration, add a suitable control, choose another application or deployment model, or accept the residual risk.

• Name who owns timeout policy and approves exceptions.
• Name who configures and tests application-level session behavior.
• For SSO, identify the identity-provider administrator and the behaviors they can confirm.
• Document hosting tasks separately from application access and account governance.
• Track every unverified behavior as an open item with a decision or follow-up.