At first glance, blocking a user may look simple: set is_blocked = true and reject the next login.
But that is not enough when the user is already signed in.
They may still have an active session, a valid token, cached permissions, or a request that started before the account was blocked.
Blocking is not a single login check. It is a change in access state that must affect all subsequent protected actions.
A Login Check Alone Is Not Enough
if ($user->is_blocked) { throw ValidationException::withMessages([ 'email' => __('auth.blocked'), ]);}This code correctly rejects a new login attempt, but it does nothing to a session that already exists.
If the user signed in yesterday and was blocked today, the next protected request may continue without checking the new account state.
That is why blocking must be enforced beyond the login flow.
Existing Sessions Need Separate Handling
An existing session does not disappear automatically when the account is blocked.
Depending on the architecture, the application may delete known sessions, revoke tokens, or check account state on every protected request.
Reliable enforcement usually does not depend on only one mechanism.
Check Account State at a Shared Access Boundary
public function handle( Request $request, Closure $next,): Response { $user = $request->user(); if ($user?->is_blocked) { Auth::logout(); $request->session()->invalidate(); $request->session()->regenerateToken(); abort(403); } return $next($request);This is only a simplified example, but it shows the core idea: account state is checked where the system already knows who is performing the protected action.
In a real application, the implementation depends on the authentication method, session type, tokens, and access-termination rules.
Permission Caches Can Preserve Stale Access
In systems with roles and permissions, some access decisions may be cached.
If account state changes but the cache continues returning an old decision, the application can behave inconsistently.
When blocking an account, understand which access data is cached, who creates it, and when it is invalidated.
A Current Request Cannot Always Be Stopped Mid-Execution
There is another boundary: a request that already passed authorization before the block happened.
If an administrator blocks the user while a long-running operation is already executing, the system cannot always safely interrupt code in the middle of a transaction.
Blocking therefore normally guarantees rejection of subsequent protected actions, not cancellation of everything already in progress.
Blocking Must Preserve Historical Data
Blocking access and deleting data are different operations.
Orders, comments, payments, messages, audit records, and other historical data may still be needed after the user is blocked.
Relationships should therefore be designed so that changing account state does not break history.
Unblocking Must Not Restore Separately Revoked Permissions
User blockedRole: editorPermission publish: revoked | v User unblocked | v Role: editorPermission publish: still revokedBlocking and permission management should remain independent mechanisms.
If an administrator separately revoked a role or permission, unblocking should not restore it automatically.
Otherwise, one "unblock" action silently reverses other security decisions.
Blocking Crosses Authentication and Authorization Without Replacing Either
During login, the system establishes the user identity. During a protected action, it decides whether that user has the required permission.
Blocking adds another condition: even a correctly authenticated user should no longer receive access.
This continues the idea from the separate article about authentication and authorization: successful authentication does not authorize every action by itself.
What to Test
1. A blocked user cannot log in.2. An existing session stops granting access.3. Protected requests check the current account state.4. Revoked tokens no longer work.5. Permission caches do not return stale access.6. Historical user data remains intact.7. Unblocking does not restore separately revoked permissions.8. A new session after unblocking uses current roles and permissions.Blocking Is an Access-State Change, Not Just a Login Rejection
If the implementation checks is_blocked only during login, it solves only one part of the problem.
Reliable blocking must account for existing sessions, tokens, permission caches, subsequent protected requests, and behavior after unblocking.
At the same time, it should not erase historical data or restore permissions that were revoked separately.
The model is simple: blocking changes whether access is allowed, but it does not rewrite user history or undo independent authorization decisions.
Blocking an account means terminating access, not merely rejecting the next login.
