Overview
This article will explain whether blocking a user will end their session immediately or upon the next login, as well as answering whether a logged in user will be logged out immediately if blocked.
Solution
Blocking a user will invalidate the current Auth0 session, so the next time the user calls /authorize to the Auth0 tenant they will be prompted to login again even when presenting non-expired session cookies, and if they attempt to use the blocked account the application will receive an “unauthorized” error stating the “user is blocked”.
However this will only affect the Auth0 session layer, if the application has a local session, this is not managed by Auth0 and thus will not be impacted by the block immediately. A user could potentially keep using the application if they do not need to get new access tokens, for example, and/or have a local cookie that allows the user to browse the application.
Access tokens are also valid until they expire, meaning there is no way to invalidate them since they are bearer tokens, even if the users are blocked. So, if users are calling APIs, it might be necessary to use short-lived access tokens to limit the length of time a blocked user could continue to make API calls if blocking access quickly is desired. Auth0 recommends using a short access token lifetime to mitigate the risk of someone copying a token and then logging out.
If needed to log users out of the application’s local session when blocking them, it is necessary to periodically poll the /authorize endpoint using the “prompt=none” parameter (AKA silent authentication) to check if the user still had a valid session on the Auth0 side:
The Auth0 SPA SDK could, for example, use the getTokenSilently method to check if the user has a session. However, note that by default, it will not send a request to Auth0 if there are valid tokens in its cache. Shorter-lived access tokens are better for synchronizing sessions between the Auth0 and local application layer, but the cacheMode can also be set to off to always send a request to Auth0. Github resources are listed below.
In the event the user is blocked (or their session has expired/logged out elsewhere), a “login_required” error will be returned when silent authentication is performed. This should indicate to the application that the user needs to log in again and that their local session should be invalidated. If they go to log in again in the browser, a blocked user will be unable to authenticate and will instead be redirected to the application’s callback URL with a “user is blocked” error.
Or alternatively, it is possible to implement a mechanism triggered on the application side when blocking the user in Auth0 to delete their local session on the application.