Removing a user's access, an employee who left, a customer you banned, someone whose account got compromised, feels like a single action from the admin panel: click delete, or click disable, done. Underneath that one click, there are actually two separate things that need to happen, and it's common for only one of them to actually be built.
The two different things
Marking a user as deleted or disabled in your database is one action: it changes a record, and it usually correctly stops that account from logging in again in the future. Whether that same user's current, already-active session, the one they were using five minutes before you clicked delete, gets cut off immediately is a completely separate mechanism, and it's the one that's easy to assume happens automatically when it often doesn't.
Why this gap exists
Most session systems check a token's validity independently of the user record it was issued for, for performance reasons, checking a signed token is fast, checking the database on every single request is slower. That's a reasonable design choice on its own. It also means a token issued before a user was disabled can keep working right up until it naturally expires, unless the app specifically checks for this case and has a way to actively revoke sessions rather than just letting old tokens quietly time out on their own schedule.
How to actually test this on your own app
- Log in as a test account and note that you're authenticated.
- From an admin account, delete or disable that same test account.
- Without logging out of the original session, refresh the page or make another request as that now-deleted account.
- If it still works, that account's access didn't actually end when you deleted it. It just stopped being able to start a new session.
Why this matters more for some situations than others
For a routine, planned departure, the gap is usually low-stakes, since there's no urgency behind the removal. For anything involving a compromised account, a security incident, or someone you're removing specifically because you don't trust them anymore, this gap is exactly the scenario where it matters most. Disabling the account in your admin panel while their existing session keeps working is the difference between believing you've cut someone off and actually having done it.
What a real fix looks like
This usually means checking the user's current status on the server for sensitive actions, not just trusting the token's signature alone, or maintaining some way to explicitly invalidate active sessions when an account is disabled, a session store you can clear, a token version number you increment, something that makes 'disabled in the database' actually translate to 'can no longer do anything right now,' not just 'can't start again later.'
Test this specifically the next time you review your app's access controls. It's an easy assumption to carry unexamined, precisely because the delete button in your admin panel looks and feels like it's already doing the whole job.