Alternate approaches to token based authentication

Question

I have a RESTful API which will be users will reach via a set of web/mobile clients, and I am trying to figure out how to handle token auth. My understanding is that traditional token auth works as follows:

1. User auths by providing user/pass, receives back a token and expiration
2. Until , token is passed with every request
3. Upon expiration, a new token is requested (either by providing a separate 'refresh' token or just by re-authenticating with user/pass)

Is there a good reason not to generate a new token with each request? That is: an initial token is requested via user/pass. This token is passed with the first API request, which returns the content of the api response plus a new token which must be passed with the following request... The advantage to this approach would be that each request (action) the user takes 'resets' the expiration of the token auth such that the token expiration time basically becomes the period of time the user can be inactive without being logged out. Is there a good reason not to use this approach? The approach laid out above seems more commonplace (which is why I ask).

Finally, one only slightly related question. What stops someone who is watching the network from grabbing the token from the user? In particular in the first scheme, it seems easy to do (in the second method, you would need to capture the incoming request and then quickly get the next token before the user does).

Answer 1

From what I read is that you want a sliding window in which a user is authenticated. Every new request within the expiry window prolongs the session. If I understand that correctly I would suggest an alternate approach; every time a request is successfully authenticated update your store in which you have your tokens and update the expiration time. This way you don't have to bother your users with all the hassle of grabbing the new token every single time. So, yes, there's a good reason not to do that: it's not necessary for your use case and only annoys the user.

With the above approach I assume that you have a store (database) in which you keep your tokens + an expiration date.

So the process is this:

1. The user provides username + password
2. Create record in store
3. Give user the token
4. Update store every time a successful request is made

On a related note; don't give the users the expiration date. That's fine when using cookies for example but that is merely useful as an additional security measure.

On your slightly related question; nothing stops anyone from grabbing the token if you don't use TLS/SSL/HTTPS. Always use TLS (which is SSL, which is HTTPS, more or less).