Why Device Session and User Account Session Are Different
After splitting Person from User, the next trap is collapsing everything that stays logged in into one session object.
Most apps have a single “session”: you log in, you get a cookie, you log out. That works until you need to answer questions like:
- Who is this browser before anyone logs in?
- Can I revoke one laptop without killing every other device?
- If a refresh token is stolen, do I invalidate the account or the device?
Those questions forced a second split: Device Session vs User Account Session.
Two layers, two jobs
| Device Session | User Account Session | |
|---|---|---|
| Exists when… | App opens (even as guest) | Someone authenticates |
| Answers | Which client / browser / app install? | Which account is active here? |
| Survives logout? | Yes (usually) | No |
| Tied to | Client fingerprint, IP, geo hints | User account + a device session |
| Compromise blast radius | One client | One login on one client |
A user account session depends on a device session. You do not refresh an account token without a valid device context. That ordering is deliberate — and it shows up again on the frontend edge.
Why guests need a device session
Rate limits, abuse signals, OTP delivery, and “new device” detection all need a stable client identity before login.
Without a device layer, every anonymous request is either:
- Stateless noise (hard to protect), or
- Forced into a fake “anonymous user” (pollutes the Person / User model)
Device session keeps guest traffic inside identity without inventing a fake person.
Multi-device becomes natural
Same person. Three clients. Three device sessions. Optionally three user account sessions on the same account.
Logout on the laptop ends the user account session on that device. The phone stays signed in. The tablet can still be a known guest.
What each session stores
Device sessions lean toward client context: encrypted IP, country / city hints, OS, browser, device brand — enough for risk signals without pretending the device is the person.
User account sessions lean toward access context: which account, which device it rides on, expiry, current refresh-token pointer.
Both use envelope encryption (per-row DEK) for sensitive fields. Sessions are not “just JWT claims.”
Failure modes that become design requirements
| Scenario | Wrong single-session reaction | Two-layer reaction |
|---|---|---|
| User logs out | Wipe everything including client identity | End UA session; keep DS |
| Stolen refresh on phone | Nuke all logins everywhere (or nowhere) | Compromise that session / family |
| New browser | Looks like a brand-new universe | New DS, then login creates UA |
| Parallel tabs refresh | One blob fights itself | Still hard — but families + edge single-flight help |
Architectural takeaway
Authentication protocols give you tokens. Session modeling decides what those tokens mean.
If “session” means both “known client” and “logged-in account,” you will eventually fight yourself on logout, theft, and guest flows.
Next
Tokens are not sessions. The next chapter covers refresh-token families, rotation, and reuse detection — the mechanism that makes compromise detectable.
Continue with Refresh Token Families.