Reassess OAuth session rotation and its costs #22

Context

Issue #7 reproduced session fixation when an attacker planted a guest JaWS cookie in a victim browser and both requests appeared to come from the same client IP. OAuth login rotation was added in v1.4.0 to stop that pre-login cookie from becoming authenticated. PR #21 in v1.5.0 coordinated the existing rotation with account linking; it did not introduce rotation.

Rotation also discards pre-login session data, requires a free JaWS session slot, and leaves in-flight requests carrying the old cookie. Its protection is limited to prior cookie knowledge: an attacker who can keep reading cookies or responses can learn the replacement too.

Examine

• Re-run the Session ID is not rotated on login (session fixation) #7 reproduction against v1.5.0, including same-IP and different-IP cases.
• State the threat model and which behavior is needed to prevent that reproduced attack.
• Compare the current rotation with any simpler defense that preserves the Session ID is not rotated on login (session fixation) #7 guarantee. Account for the new-session capacity requirement, pre-login data loss, and stale-cookie requests during login and logout.
• Record an evidence-based keep, simplify, or revert decision. Any removal needs a replacement defense and a regression test for Session ID is not rotated on login (session fixation) #7, plus OAuth login/link/logout coverage.