9

I've finished designing a RESTful API, in which I authenticate each request with an API Token that's sent as a param.
Now I want to create a client interface, and I was wondering what's a properly secure way to manage a session with each browser client.

I've thought about a flow to keep the server side stateless:

  • web client logs in with user and password
  • server responses with the user's API Token
  • client stores the token as a cookie
  • client sends the token as a param with each request, as the API server expects

But something doesn't seem right to me here... isn't this too vulnerable?
Let's assume I'm using SSL, but still,
can't the API token be stolen easily that way?
Is it even a proper way to work?

3 Answers3

12

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

Saikrishna Radarapu
  • 377
  • 4
  • 13
  • 1
    Please note that though the link mentioned in the answer is related to JWT, also a token. Hence you can store your custom generated tokens as mentioned in the link. – Saikrishna Radarapu Nov 21 '17 at 09:22
  • JWT is protection against man-in-middle attacks. It's not really applicable to authentication as such. Especially since properly set up TSL for HTTPS will provide the same functionality, but faster and with better algos. – tereško Nov 25 '17 at 17:34
  • And, yes, the CSRF protection is a nice benefit, but it is only one of the attack vectors. – tereško Nov 25 '17 at 17:44
6

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.

tereško
  • 58,060
  • 25
  • 98
  • 150
0

Note that RESTfull API does not need an interface and is stateless. Your question can be considered in two cases:
1: In the first case, you have a server that is only a REST_API server and has no interface and have json responses for valid requests, other servers(from different IPs) send their requests, so you cant manage clients with sessions because its a server to server communication and every server will have just one IP.so token is your best choice.
2: In the second case you have provided the same capabilities but you wana have an interface beside your REST_API in the same server, now just for your interface you could use session and for others(other servers) use token.
In both cases, the best way is to use token. you can use JWT token which is signable and more secure.
Also note that when everything is on same server, you can use session for your own interface for that server.

Msd.Abd
  • 108
  • 1
  • 5