Session ID Rotation and Logout: Should Rotating Identifiers Share a Common Revocation Boundary?

[GioeleB00]

Hi everyone,

I've recently been investigating session rotation and logout semantics in lua-resty-session, used by lua-resty-openidc and Apache APISIX.

During controlled tests, I observed an interesting behavior related to session ID renewal and revocation:

1. An attacker obtains a copy of the victim's session cookie (SID A).
2. The victim's session rotates from A to B.
3. During the stale_ttl grace period, the attacker uses A and obtains a new authenticated session C.
4. The victim logs out using B.
5. C remains authenticated until its own timeout, despite the victim's logout.

The maintainers confirmed that this behavior is consistent with the library's design. I'm not presenting it as a vulnerability or disputing that assessment.

However, it raises a broader security design question: should rotating session identifiers derived from the same authenticated session share a common revocation boundary?

I've written a short design discussion proposing a stable logical session referenced by rotating SIDs, where logout revokes the entire session lineage without affecting independently established logins.

Design discussion:
https://github.com/GioeleB00/session-lineage-revocation/blob/main/Session_ID_Rotation_and_Revocation_Design_Discussion.md

I'd particularly appreciate the community's perspective on two questions:

1. Is logout-revokes-the-session-lineage a useful security invariant for server-side session management, distinct from subject-wide revocation?
2. Could a stable logical session with rotating SID aliases offer a safer revocation model while retaining the concurrency tolerance described by OWASP? What important counterexamples or weaknesses might I be overlooking?

I'm especially interested in critical feedback, alternative designs, and perspectives from engineers who have worked on session management systems.

AI assistance disclosure: AI tools were used to assist with drafting and refining the written presentation. The technical design, proposed security invariant, and underlying engineering decisions are my own. I take full responsibility for the proposal, its technical accuracy, and its contents.

Thanks for your time!

Gioele Botta

[santipaez]

Short answer: yes, "logout revokes the whole SID lineage" is a useful invariant — but it is not what stale_ttl is for, and the cheat sheet already implies it while explicitly tolerating the overlap window.

Two mechanisms are being conflated:

1. Renewal overlap (intentional). Session Management Cheat Sheet → Renewal Timeout says the previous SID "would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID", and even documents the race you reproduced — an attacker holding the pre-renewal SID can beat the victim to the first post-renewal request. Removing the window breaks legitimate in-flight requests.
2. Lineage revocation (the actual gap). Your observation is not "the grace window exists" but "a session derived from a stale alias becomes a new root". Logout of B revokes B; C has no pointer back, so nothing can revoke it. That is independent of window length.

Minimal model preserving concurrency tolerance:

• session_id (logical, stable, bound to the principal at authentication) + sid_alias (the rotating cookie value).
• Per alias: alias -> {session_id, generation, issued_at, expires_at}. Per session: {session_id, principal, revoked_at, generation}.
• Rotation increments generation; accept an alias only if n >= current_generation - grace_generations — a count, not a timestamp (avoids clock skew across nodes).
• Minting from a stale alias is allowed only inside the grace window, must not outlive session.expires_at, and is capped per generation, so an attacker cannot indefinitely re-mint.
• Logout is idempotent: write a tombstone on the session first, then delete aliases. Tombstone TTL must exceed the longest possible alias lifetime, else a pruned tombstone resurrects C.
• The check rides on the session record already loaded per request, so no extra store read.

Weaknesses I'd expect reviewers to raise, against your Q2:

• Device conflation. If a lineage is per-user rather than per-browser-session, "logout revokes the lineage" silently becomes subject-wide revocation (logs out other devices). Create the lineage per client at authentication; treat remember-me / refresh-token families as a separate lineage with its own reuse detection (OAuth 2.0 Security BCP §4.13.2 is the closest well-specified analogue).
• Ordering ambiguity. With a shared cookie jar, attacker and victim are indistinguishable by request order — which is why a generation cap does more work than shrinking the window.
• Node locality. A tombstone kept in one web node's memory is node-local; you need a shared store (redis/etcd) or broadcast invalidation, or revocation silently differs per replica.
• Availability tradeoff. Per-request revocation checks mean a store outage either fails closed (logs everyone out) or fails open (revoked sessions pass). State that choice explicitly.
• Silent failure. Best-effort alias pruning without a tombstone reproduces exactly your C case, only harder to detect.

(Also worth adopting the cheat sheet's session-logging guidance keyed by lineage id — it makes the invariant testable.)

[GioeleB00]

Thanks for the detailed feedback!

Just to clarify, I'm not proposing to remove or shorten the grace period. The distinction between renewal overlap and lineage revocation is precisely what motivated this discussion.

The stable logical session with rotating SID aliases is also the core of my proposed design.

I particularly appreciate your additional points about generation limits, tombstone lifetime, and failure handling. Those are useful considerations for a concrete implementation.

Thanks again for taking the time to review it!

[santipaez]

Glad the distinction landed — agreed that the grace window is not the bug; the missing link is that an alias minted during the window must inherit the lineage's revocation state.

If it helps, the invariant I would test is:

• every alias carries (lineage_id, generation); minting is allowed only while generation >= current - grace, and the minted alias never outlives the lineage's expires_at;
• logout writes the tombstone on the lineage before deleting aliases, and the tombstone TTL is strictly greater than the longest alias lifetime (otherwise a pruned tombstone resurrects C);
• a revoked lineage rejects every alias, including one minted during the grace window, on every node (shared store or explicit invalidation).

The one design choice I would still call out: whether the lineage is per-client or per-user. Per-user makes "logout revokes the lineage" log out every device; per-client keeps it honest, with remember-me and refresh-token families as a separate lineage. The OAuth 2.0 Security BCP's refresh-token family reuse detection is the closest well-specified analogue.

Happy to sketch the state table if that is useful.

[zhameersheraz]

Two things the tombstone model still needs to pin down, both unrelated to revocation itself: what an alias is allowed to see, and what the client can prove.

1. Logout is not always a destroy. The README says session:logout() "either destroys the session or just clears the data for the current audience, and saves it", and that with a single audience it equals session.destroy. Revocation covers session:destroy and the last-audience logout, not the previous identifier on session:save or a partial logout. So with multiple audiences, logging out of app X rotates the cookie: the identifier just used to log out stays usable for stale_ttl, and still carries app Y's session. Revoke every key derived from one authentication, including the one the logout itself produced. The tombstone goes in before the clearing-save, and its TTL has to cover the stale_ttl window of the identifier that logout generated.

2. The boundary should be per (authentication, audience), not per cookie. One cookie here holds several audiences with per-audience logout, so a cookie-level boundary means logging out of app X also revokes app Y. That is subject-wide revocation in disguise. store_metadata already indexes sessions per audience and subject, so a lineage id could live in the existing metadata record.

3. The alias needs a state model. session:save() copies the data forward, so C is a fork of A's data as of the rotation. As a view on the lineage state, the attacker's alias sees the victim's post-rotation state and becomes a live read/write window into it, which is worse than a bare stale id. As a fork snapshot, you need write-conflict semantics, and the fork can carry stale security state (an "MFA satisfied" flag, scopes, enforce_same_subject), so an attacker holding a pre-MFA copy keeps a pre-MFA session. Either way the lineage record has to own the security-relevant state, and the alias should carry only (lineage_id, generation).

4. Revocation has to be closed under the derivation graph, and the defaults are fail-open. revocation_fail_mode defaults to "open", so an unreachable revocation store means a revoked session is accepted anyway. revocation_cache_ttl and revocation_error_cache_ttl default to 5 seconds of worker-local caching, so a tombstone written on one worker can stay invisible on another for five seconds. "Every alias rejected on every node" needs a shared store with a tighter cache or explicit invalidation, and five seconds is enough for an attacker holding C to land a few requests.

5. Better: stop treating the identifier as a bearer token. The library has a weak version already, bind = { "ip", "scheme", "user-agent" } MACs those values in, which is prevention rather than detection, and worth a mention in the cheat sheet's "Binding the Session ID to Other User Properties" section. The strong versions are cryptographic: TLS channel binding (RFC 5056, RFC 5929 tls-unique/tls-server-end-point, RFC 9266 tls-exporter for TLS 1.3) binds the session to the client's TLS channel so a replayed cookie fails, and proof of possession (RFC 9449, DPoP) has the client sign each request with a key in a non-exportable store, which makes SID A useless on its own. That composes with the lineage model rather than replacing it: A cannot be used at all, so C is never minted, and you keep lineage for a compromised client, for clients without PoP, and for refresh-token families. Channel binding breaks behind TLS-terminating proxies and CDNs and with mobile IP churn, and PoP does not help when the endpoint itself is compromised.

6. Cheat-sheet delta. The Session Management Cheat Sheet has no occurrence of "lineage", "alias" or "stale", so this is uncovered. Under "Session ID Life Cycle" I would suggest three sentences:

1. Rotation overlap (see "Renewal Timeout") is a concurrency mechanism, not a revocation mechanism: an identifier issued before the client learns the new one stays valid for the overlap, and the server must be able to revoke every identifier derived from one authentication, including those issued inside the overlap.
2. Any identifier derived from an authentication (rotated session IDs, remember-me cookies, refresh tokens) must be revocable by a single revocation operation, and the revocation state must be visible to every application node and outlive the longest-lived derived identifier.
3. Where a session identifier is bound to client properties or to a client-held key, enforce the binding cryptographically (MAC or signature) rather than comparing heuristically, and state what happens when the revocation or binding store is unavailable.

Your two questions. Both yes. I would phrase Q1 as "revocation is closed under the derivation graph" rather than "logout revokes the lineage", because that graph has more edges than SID rotation (audiences, remember-me, refresh tokens) and the closure property survives a redesign of the cookie format. For Q2 the shape is right, and the two things missing from the list are the state semantics (view or fork) and the boundary (per authentication and audience, not per cookie).

---

AI assistance disclosure: AI tools were used to check the cited library documentation, cheat-sheet text and RFC references. The analysis, the points and the wording are my own.

[mackowski]

Do you think this is resolved in this PR #2893?

[GioeleB00]

The merged PR addresses the original session ID lineage revocation invariant, including grace-period aliases and concurrent operations.

The additional points raised here, particularly multi-audience semantics, session state consistency, and revocation-store behavior, are valuable but go beyond the scope of that change.

The goal of the PR was to clarify the required security property without prescribing a specific implementation. I was asked to write max 1 or two sentences from Jim.

So in my opinion the PR clarifies the invariant, if you consider usefull add a sketch of a possible implementation, we may use this really interesting discussion as starting point, but I think this would require a separate PR.

[mackowski]

@jmanico what is your take on this?