A rotation log entry that reads success tells you a token was replaced. It does not tell you the session behind that token is still the same one an attacker stole last week. This piece explains why the two layers drift apart, what a payments team found in its own post-mortem, and which logging changes close the gap without a rewrite.

The Log Says Rotated, The Attacker Says Otherwise

Rotation jobs report on the token lifecycle. They count refreshes, flag expired credentials, and mark each cycle complete. What they rarely record is which session consumed the new token, or whether that session had already appeared from a second address. The log looks healthy because it is answering a narrower question than the one responders ask at 2 a.m.

Refresh tokens often sit outside the audit scope entirely. They are long-lived by design, stored in browser storage or a cookie, and treated as plumbing rather than secrets. When a session key is stolen, the attacker does not need to defeat rotation. They present the same session and let the legitimate user's client keep rotating tokens in the background.

Detection then lags the rotation event by hours or days. The rotation succeeded, the user stayed logged in, and nothing in the token log distinguishes the attacker's requests from the victim's. A related piece on this site about maintainer contracts and on-call hours makes a similar point about where operational work actually lands.

What Session Hijacking Actually Looks Like

Session hijacking is the reuse of a valid session key to reach an authenticated service. The classic route is cookie theft through an intermediary or from saved browser storage, as described in the general literature on the topic. The attacker does not crack a password or forge a token. They copy a cookie and replay it.

Valid session keys bypass rotation because rotation never touches them. A refresh token can be rotated every few minutes while the session identifier stays fixed for the life of the login. The attacker holds the session, not the token, so the rotation counter climbs and the intrusion continues.

The logs show legitimate user activity because the requests are legitimate in form. Same endpoints, same permissions, plausible timing. Only the network origin and the device fingerprint differ, and many stacks do not join those signals to the session record. The intrusion hides in the shape of normal traffic.

There is a second reason the shape looks so ordinary. Session identifiers are frequently opaque random strings with no embedded claims, so nothing in the value itself says which device or login produced it. A signed token at least carries a subject and an issue time that a log can parse. A bare session key carries nothing, which means the only context available is whatever the application chose to write down at login time. If that context was never written, it cannot be recovered later.

A Post-Mortem From A Payments Team

A payments engineering group ran rotation every 15 minutes and kept its token logs clean for months. During a routine review, an analyst noticed a session that had persisted for several days across two continents. The rotation log showed no failures. The session had simply never been asked to prove it belonged to one device.

The root cause was a refresh token stored in browser-accessible storage, paired with a session identifier that the auth service never logged. The team could see every token rotation and none of the session-to-token linkage. Their audit covered the credential layer and missed the session layer sitting directly beneath it.

This is the gap that tooling tends to reproduce. Rotation vendors instrument the token lifecycle because that is the product surface. Session state frequently lives in a separate service, a cache, or the application itself. No single dashboard owns the join, so no alert fires when the two records disagree.

The team's remediation is worth noting because it was cheap. They added the session identifier to the refresh log line, kept the existing rotation cadence, and built one alert that compared the network origin of consecutive refreshes for the same session. The first week produced a handful of pages, most of them travellers on mobile networks switching between carrier addresses. They added a tolerance for sessions whose addresses changed within a single country and kept the cross-region case loud. The remaining signal was small enough to investigate by hand.

Why The Blind Spot Persists

Rotation tooling focuses on token lifecycle metrics because those are easy to define and sell. Session binding is harder: it requires agreement on what identifies a session, where that identifier is stored, and which service is allowed to write it. Teams measure rotation counts because the number is available, not because it predicts compromise.

Session state often lives outside the auth service. A load balancer, a Redis cluster, or the application framework may hold it, and each keeps its own view. Joining those views to the token log is an integration project, and integration work loses to feature work on most roadmaps.

Vendors rarely log session-to-token linkage because their contracts stop at the token. The customer owns the session layer. That division is reasonable commercially and dangerous operationally, since the attacker operates precisely in the seam. A related piece on Postgres wire protocol changes covers how client libraries absorb protocol shifts, which is the same class of integration debt.

Retention policy compounds the problem. Many organisations keep authentication logs for a compliance window measured in weeks while session records expire in hours. By the time an analyst suspects a stolen session, the cache entry that would have proved it has already been evicted. The token log survives because it is small and structured. The session record, which is larger and noisier, is often the first thing aged out.

Engineering The Missing Link

Binding sessions to rotation events means writing the session identifier into the same record as the token identifier. When a refresh happens, the log line carries both. Responders can then ask which sessions rotated from which addresses, and spot a session that rotates from two networks within an hour.

Treat refresh tokens as high-value secrets. Store them in httpOnly, Secure, SameSite cookies rather than browser-accessible storage, and shorten their lifetime where the product allows. This does not stop session theft on its own, but it removes the easiest collection path and shrinks the window an attacker can use.

Alert on session reuse across IPs and on session-token mismatch. A session that presents a freshly rotated token from a new autonomous system is worth a page, even at low volume. The cost is alert fatigue if thresholds are loose, so start with a small allowlist of known corporate ranges and tune from there.

There is a trade-off worth naming before anyone commits to it. Shorter refresh lifetimes and stricter binding both increase the chance that a legitimate user on a flaky connection gets logged out mid-task. Payments flows are exactly where that hurts most, because a dropped session during checkout costs revenue and generates support tickets. The workable compromise is usually to bind strictly on the refresh path while leaving short-lived access tokens forgiving, so a network blip forces a silent refresh rather than a full re-login. Teams that skip this distinction tend to ship the strict policy, watch complaint volume climb, and then quietly roll it back.

Four Actions For This Quarter

Map where session state is stored for each authenticated product, including caches and load balancers, and write down which service owns the write. Add the session identifier to every rotation log line so the two records can be joined without a separate pipeline. Set an alert for session-token mismatch and for a single session rotating from two distinct networks inside an hour. Review cookie storage and flags on every refresh token, and move any token in browser-accessible storage behind httpOnly and Secure. None of these require a new vendor. They require someone to own the seam between the session layer and the token layer, which is where the attacker already works.