This is what we do for our applications,
First, we send the username and password to the server from our application.
On the server, they authenticate credentials and return a response, which is a combination of the request token and sucess flag.
In our application, we check the sucess flag. If its value is true, we save the request token and use it for all subsequent outgoing requests to the server.
Now, when the server receives the request, it checks the database to see if the user has this token. If so, it checks the time at which the last request was made. (This applies when the user login time has expired.). If the difference between the current time and the time of the last request is more than the limit you set, you will respond to this application that a new entry request is required to receive a new token. Otherwise, you continue the request and respond to the results.
This is how the server-side guys do it at my workplace. Im working on the client side. But this is basically what has been done.
Edit: about token. Its basically a 32 character string that is randomly generated. Therefore, when the user sends a login request and the login is successful, we create a token using the generator method and save it in our server database as a user token with the current time and date.
So, when the user sends another request to the server, we first take the token and check if the user exists with this token. If there is, then the next check is to see if this is an old request marker. Therefore, we check the current time with the time stored in the database. If the request was sent to the limit (for example, 5 minutes), we update the last time of the request in the database with the current time and return the result to the client.
Using this method, you authenticate for each request by checking the token and time of the last request.
Suppose you want your application to register all the time until a user error terminates. In this case, you do not need to check every request time. All you have to do is save the request token on the client device. And when the user selects, remove the token from the client. Therefore, he will have to enter the next time, since he does not have a token. Its bit is safer for storing a request token on a client device than storing a username and password in this scenario.
There are many functions for generating random tokens.
blessenm
source share