Backend Development 6 min read

How to Enforce Single-Device Login with Session, Token, and JWT

This article explains three backend strategies—session‑cookie, token, and JWT—to ensure an account can only be active on one device at a time, detailing the workflow, data structures, and Redis integration needed to implement forced logout across multiple endpoints.

Lobster Programming
Lobster Programming
Lobster Programming
How to Enforce Single-Device Login with Session, Token, and JWT

In many real‑world applications a single account must be allowed to log in from only one location, such as video platforms that need to prevent a VIP membership from being shared. The typical solution is to force a logout of the previous session when a new login occurs.

Below are three common implementations for forced logout.

1. Session‑Cookie Approach (Monolithic Architecture)

The core of this method is the sessionId issued by the server to the browser. A global Map<sessionId, session> is used to track active sessions.

(1) When User 1 logs in with Account A, an interceptor checks the global map for an existing session.

(2.1) If a session exists, the account is already logged in elsewhere; a dialog asks whether to force logout. If confirmed, the old session is removed from the map and the new session‑sessionId pair is stored, causing the previous login to become invalid.

(2.2) If no session exists, the new session and its sessionId are directly stored in the map.

(3) The server returns the sessionId to the client.

(4) A session listener monitors creation and destruction; when a session is destroyed, it is removed from the global map.

2. Token‑Based Approach

After a successful login, the server generates a unique token and stores a userId‑token mapping in Redis.

(1) User A logs in; the server checks Redis for an existing token for that userId .

(2.1) If a token exists, the account is already active elsewhere; the user is prompted to force logout. Upon confirmation, the old token‑userId entry is deleted and a new token‑userId mapping is saved. Subsequent requests with the old token will fail, requiring re‑login.

(2.2) If no token exists, the new token‑userId mapping is saved directly.

(3) The token is returned to the client.

3. JWT‑Based Approach

In a JWT scheme, user information is stored inside the token itself, and the server does not keep session state. Validity is determined by successful parsing and expiration checks. To enforce forced logout, the issued JWT is also cached in Redis with a userId‑JWT mapping, and the same Redis‑based workflow used for tokens is applied.

Summary

Session‑cookie login can use a global Map to enforce single‑device login.

Token and JWT login can leverage Redis to store userId‑token/JWT mappings and achieve the same forced‑logout behavior.

Redisforced logoutJWTtoken authenticationSession ManagementSingle Sign-On
Lobster Programming
Written by

Lobster Programming

Sharing insights on technical analysis and exchange, making life better through technology.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.