4

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?

| improve this question | |
2

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.

| improve this answer | |
  • Can you implement step-up authentication if the cookie is older than N hours, or if the transaction is above R risk level? The cookie remains, but the use is required to re-authenticate (potentially with a less challenging authentication, since the cookie indicates that it is within an authenticated context?) – Mark C. Wallace Jul 17 '14 at 12:34
  • But it's okay, that the key can be used more than once? I mean, doesn't this leave me wide open to MITM attacks? – Kao Jul 17 '14 at 12:52
  • @Kao Yes it is ok. But you need to be sure that your website is using HTTPS. No cookie will ever be safe if you don't use HTTPS because an attacker could simply read the cookie in the traffic. HTTPS also has the advantage to protect you against replay attack, another form of MITM attack. Using HTTPS, each time you send the cookie it will be encrypted differently because at the start of each message a different IV is used and a different key is used for each successive connection. – Gudradain Jul 17 '14 at 12:55
1

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).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.