Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
If you have a REST API, which when you log in from the client side, generates an access token for the client, which is then stored in local storage and used for all authentication from this point on.
Is it secure to keep using the same access token, say you generate the access token, store it in the database, and keep using this access token till the client actively presses log out?
If no, what would be the requirements to make this secure?
Yes and no.
What you are talking is like an authentication cookie.
Yes because unless the computer is compromised, physic access or virus, the cookie is safe and only the source computer can use it. Many site do that, for example this one. Even if I close my browser or computer, I'm still logged in because the cookie stay in my browser which reside on my personal computer.
But, only do that for non-critical service.
No because the longer an authentication cookie stay alive the more chance it has to be stolen. For example, would you like to stay logged in to your bank account? A "friend" come at your house, you leave your computer open. He access your bank account because you are still logged in and steal some money. Friend do that all the time with opened facebook account. Also the longer is stays active the more chance it has to be stolen, no matter how it is stolen.
The shorter the live of your cookie the more secure it is. But for non critical applications, it's ok to have cookies that live a long time and persist after we close the browser.
There is a lot of documentation on this subject already - some very detailed articles are available here and here.
The point of an API is to offer access to data. This access can be either public or private, but if it's private access then your job as an API developer is to secure the access to your API. How your clients choose to implement their own security layer to provide access to the API with their credentials, is up to them - for example, login for a site that offers it's registered users access to data loaded from your API can be implemented independent of your API's access layer, since the server-side of that website is the one that's actually authenticating itself and talking to your API.
On the other hand, if you provide an API that will actually be used directly from the client side - let's say, AJAX requests form the client's browser to the API - then you can think of either publicly exposing part of your functionality or provide some means of linking the calls in such a way that the end-user can authenticate before using your API (think more or less something similar to what payment gateways are using for third-party authentication into their system).
