Proper Session Management with REST API

Store your tokens in cookies for web applications, because of the additional security they provide, and the simplicity of protecting against CSRF with modern web frameworks. HTML5 Web Storage is vulnerable to XSS, has a larger attack surface area, and can impact all application users on a successful attack.

Refer this link below:

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

In proper REST you can't do session. Since they tend to be stored on server.

Therefore, you would need to re-identify the user for each request.

What you currently have is the OAuth approach. You issue a token, which, when provided, will be be assumed as proof of identity. If anyone manages to steal that token, there is not simple way to detect it. As for "how it can be stolen", the major vectors are XSS, browser extensions and physical access. You can mitigate XSS, but you really can't do anything about the latter two.

There is also CSRF as a vector, as @Saikrishna Radarapu mentioned, but, if you store your token somewhere, that is not a cookie, it's not really a concern.

So ... potential options.

Simplest approach would just add expiration times for your authentication tokens. When token has expired, you ask the user to re-login. This way a successful attack will result in an ... emm .. window-of-opportunity, which you can further limit by asking users to re-enter password, when performing destructive operations.

Another option is to model the tokens based on this approach for remember-me cookies, but this approach has a serious drawback - it doesn't play well in asynchronous environment. You can mitigate it by applying "fuse" for each token - mark it "volatile" on first use and assign it X seconds of "burn time". Withing those X seconds keep returning the same "new" token, and then mark the original token as "expired".

The third option, that I have head about, is to just use either HTTP Basic Auth or Digest Auth, but I have never actually tried those in practice.

So ... these are my two cents on the topic.