Admin panel bans a user, but the App can still place orders—why can't JWT be revoked?

Conclusion first: if the requirement explicitly says that banning an account, kicking a user offline, or logging out other clients after a password change must take effect immediately, prefer a server-revocable login state (typically Session or a server-side session table); if you also need to serve an App, mini program, and open API, and can accept second-level to minute-level revocation delay, then use JWT plus a user-level version number or jti blacklist. Both approaches support multi-device login. The difference is not performance, but who must be touched to revoke one login state.

First look at revocation capability: deleting a record and waiting for expiration are two different things

Session keeps a session record on the server; the browser only receives an unguessable session ID, and every request looks up the record to determine who you are, whether it has expired, and whether it has been kicked. JWT signs the user identity and validity period into the Token, so the server can verify the signature without a database lookup, which is also why it is convenient in cross-service calls.

The cost is that after a JWT is issued, it cannot be directly revoked. Requirements such as banning an account, kicking a user offline after login from another location, or clearing other clients after a password change directly determine the solution. To achieve an equivalent effect with JWT, you usually need to add a user-level version number or a jti blacklist, adding one cache lookup to every protected endpoint. A common practice in 2026 is to validate uniformly at the gateway, avoiding each service writing its own implementation.

• Session cost: needs shared storage (commonly Redis) so multiple instances can share the session; if storage is unavailable, login state fails as a whole.
• JWT cost: server-side statelessness and easy scaling, but logout, forced offline, and immediate permission changes all need extra implementation.
• Shared cost: both must handle the window after a token is stolen; the difference is only window length and remediation measures.

Check against four conditions; revocation timeliness comes first

1. Deployment form and number of instances: with a single instance or a few instances and existing shared cache, Session has low implementation cost; if instances scale up and down frequently, JWT is smoother.
2. Clients and domains: if you only have same-domain web pages, Cookie + Session is simple; if you must also serve an App, mini program, and third-party open API, Token avoids Cookie domain and SameSite pitfalls.
3. Revocation timeliness: for scenarios that require immediate effect, Session naturally satisfies it; JWT needs extra mechanisms, and the common experience range is an additional 1 to 3 days of development and integration effort, moving toward the upper bound as the number of clients increases.
4. Operations and troubleshooting: Session depends on shared storage, adding a layer of availability requirements; JWT scales easily, but troubleshooting request identity depends more on the jti or user ID in logs.

If item three is written as must take effect immediately, the scaling convenience of item four usually has to give way; conversely, if item two includes an App, mini program, and open API at the same time, the adaptation cost of a Cookie solution often exceeds adding a blacklist layer to JWT. After checking all four, usually only one or two candidates remain.

After deciding on JWT, where to store the token and how to renew it are where problems often appear

Storing the token in localStorage lets XSS read it directly, while storing it in a normal Cookie introduces CSRF unless SameSite and CSRF validation are also configured. Based on common delivery practices in 2026, a relatively stable combination is a short-lived Access Token plus a long-lived Refresh Token: the Access Token is kept only in memory, while the Refresh Token is stored in an httpOnly + Secure + SameSite Cookie, issued by the server, and revocable.

The typical range for Access Token validity is 15 minutes to 2 hours, and Refresh Token is 7 to 30 days (both are experience ranges; adjust by business sensitivity). If set too short, refresh frequency is high, and concurrent frontend requests can easily trigger multiple refreshes at the same time, requiring client-side single-flight; if set too long, the exploitable window after token leakage becomes longer, and revocation capability relies more on a server-side blacklist.

• Option A: Session + shared storage: revocation is direct, deleting the record invalidates it immediately; cross-client adaptation cost is higher; adds a layer of storage availability requirements; suitable for same-domain admin panels, monoliths, or a few services.
• Option B: JWT + Refresh Token: cross-client and gateway uniform signature verification costs are low; services are stateless and easy to scale horizontally; revocation needs extra mechanisms; suitable for multi-client online, service decomposition, and open APIs.

Delivery reality: ban requirements often arrive earlier than expected

A common situation is tight budget and schedule, the requirements document only says mobile number and password login, and developers directly sign a long-lived Token without building a Refresh mechanism or logout API. Two or three weeks after launch, operations asks to ban accounts, and only then do you discover that the original Token still works after banning. You can only add a user-level version number table temporarily, add one extra check to every protected endpoint, force all existing login states to expire, and make users log in again. The typical range for this kind of rework trigger is 1 to 4 weeks after launch, and the cost is one all-user re-login plus a round of regression testing.

To avoid this, just ask one more question during solution selection: will there be requirements to kick users offline, ban accounts, or change permissions within three months? Write the answer into the solution description, then decide whether to use pure JWT or JWT plus a version number. Checking login-state acceptance items during delivery is easier than fixing them after launch.

Where it fits and where it does not

The cases suitable for JWT are fairly clear: the same account needs to be online across an App, mini program, and web; services have already been split or need unified authentication through a gateway; you need to expose APIs to third parties; or you want stateless services for scaling at any time. The cases suitable for Session are equally clear: same-domain admin systems, a monolith or a few services, a hard requirement for immediate forced logout, limited team operations capacity, and existing shared cache available.

The boundaries should also be written clearly: if it is only an internal tool, the user count is in the tens to hundreds, and there are no multiple clients or open APIs, the difference between the two approaches is small. Just choose the one the team knows better; there is no need to introduce a Redis cluster or blacklist service solely for login state. Conversely, if the business requires permission changes to take effect in near-real time and there are many services, the revocation weakness of pure JWT becomes a long-term maintenance burden. A more reliable approach then is unified authentication at the gateway while keeping server-side session state.

FAQ

Is JWT always better in performance than Session?

The difference per request is usually small. What JWT saves is mainly one session lookup; the real bottleneck is generally the database and network. When user volume is not large, performance should not be the reason for choosing one.

Can JWT still implement forced logout?

Yes, but it requires extra mechanisms. Common approaches are maintaining a token version number or jti blacklist for the user and comparing it during validation; the cost is one extra cache lookup on every protected endpoint.

With separated frontend and backend, must Session be replaced with JWT?

No. Frontend-backend separation and login-state approach are two different things. As long as cross-origin Cookie carrying is handled properly, plus SameSite and CSRF validation, Session can work just as well.

For multi-device login, how many devices online should be limited?

The typical range is 1 to 5 clients. When exceeded, kick the earliest logged-in one, and record the device identifier in the session record or version table to avoid handling only the current client and not the others.

Next step, write a one-page conclusion first: write one sentence each for deployment form, number of clients, revocation timeliness, and operations cost, then decide the approach. If you choose JWT, be sure to also define the Refresh mechanism, logout, and forced-logout paths, and put them in the delivery acceptance checklist. If revocation requirements are not yet decided, launch with Session first and encapsulate login state in one place, so later replacement has a more controllable change surface.