User Logout

Last updated: March 30, 2020

To process the user logout, your application can use any existing user logout scenarios, such as cleaning authentication cookies on a user's web browser, and revoking or removing an authentication token, that your application had issued. In short, the logout process remains completely unaffected by Meveto. However, since Meveto allows users to be able to logout of client applications from their Meveto dashboards as well, there is an additional step that you need to implement in your app, to allow Meveto to log users out, and that is the user logout event. When a user requests a logout from your app, Meveto will trigger an event that will dispatch a webhook call to your application's webhook URL which you have specified at the time of registration of your app with Meveto.

Your app should simply acknowledge the reception of the event, by responding with a 2xx HTTP status code to the webhook call. If your app fails to respond with a 2xx status, or if the webhook actually fails for a reason and doesn't make it to your application, then Meveto will try to attempt making the call at least 2 more times with exponential back-off strategy. If all the attempts fail, then Meveto will send an email about the issue to your registered email address. You must ensure that your app never miss any webhook calls from Meveto. To help you with this, Meveto also offers the webhook API which your application can consume to check for any pending calls. Normally applications can rely on properly set up webhook listeners from Meveto, but if your app is of a sensitive nature, then we highly recommend that you maintain an automated script, such as a cron job, to periodically check with the Meveto webhook API, and thereby never missing any user related events.

The user logout event

In the webhook call to your app, Meveto will indicate the nature of the event by a type attribute inside the payload of the call. In case of a user requesting logout, the type will be User_Logged_Out. Also in the payload, there will be a user_token attribute. Certainly your app will need to identify the user that is requesting the logout. For this to work, your app should use the user token to retrieve Meveto ID of the user. This user token will be unique, and every time your app will receive a new token. With that being said, your app should not store the token as it is good for one time use only. This arrangement allows for a seamless security and integrity, without relying on the need for encrypting the payload of the webhook at all. You can read further technical details at the user endpoint. Once your app successfully retrieves a Meveto ID in exchange for the user token, your app can then further process the logout as per the required business logic. Obviously, the first step would be to identify the local user associated with that Meveto ID.

The most important thing to keep in mind here is that this process was invoked by a webhook call to your application from Meveto. Therefore, current execution of this process does not have any link with the user's browser or any user interface. Your application might be using browser cookies or an authorization token for user login. There are two recommended ways of logging the user out.

Cookies or Session based logouts

When your app receives the user logout event webhook call, after identifying the user, set their last_logged_out attribute to the current time, and this should essentially complete the process of logout. There should be a global middleware, or a method, that must run before each protected page of your application is accessed. In this middleware or method, you will need to check if the last_logged_out value for the current user is later than the last_logged_in value. If this is later, then it means the user has requested to logout from your application, and your app has processed the webhook call by updating the last_logged_out value. Therefore, you should immediately clear authentication cookies/sessions of the user's browser and redirect the user to another location. This ensures that if logout is processed for a user, then the very next request from their browser will complete the process.

Token based logouts

If your application is using access tokens, such as JWT tokens, for authentication then the process will be relatively simple. After identifying the user from the webhook call, all you need to do is to revoke or delete the current access token, or all access tokens in case there are more then one tokens issued (user could be logged in to more than one device). But for this to work, your application must be keeping track of access tokens that it issues, typically by storing necessary information in the database. However, if access tokens are not stored and managed, then you can implement a similar approach as described in the cookies or session based logouts. The only difference would be to invalidate an access token in the global middleware, where otherwise you would clear authentication cookies or sessions.

Auto logout with websockets

User experience is an extremely important aspect of any application. To ensure a seamless experience where your app automatically reloads and logs the user out (without waiting for the next request), you can use websockets for this purpose. With websockets, when the user logout process is complete as per the above details, your app can then trigger or broadcast the logout event, that your websocket service will listen to, on the user interface (such as browser) of your app. This requires the use of front-end scripting, such as JavaScript based services that will, upon detecting a logout event, reload the user interface, and take the user to any page you want such as the login page. This will make the logout process a smooth, and satisfying experience for your users, that happens in real time. There are managed services that offer websockets as a service, and that can be very easily integrated with applications. For further information, take a look at Pusher or


Meveto is not associated, nor benefit from the use of any third party services mentioned here. Pusher, or others have only been mentioned for the purpose of information of the reader.