2

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

arcologies
  • 742
  • 1
  • 6
  • 22

1 Answers1

2

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

harm
  • 10,045
  • 10
  • 36
  • 41
  • I am using python w/ itsdangerous TimedJSONWebSignatureSerializer (a JSON Web Signature implementation). So no, I don't think I am using a database to store tokens. And because the expiration is part of the token, you cannot extend it (you would get a new token). To clarify: the 'users' of the API is myself (end users are not intended to use the API directly, just use one of the client apps). So I was mostly concerned with security implications of this approach. – arcologies Feb 10 '17 at 18:20
  • Also - the reason for the expiration in the 'standard' model is so that the client can know when to request a fresh token without having to hit the resource, be denied due to auth failure (token expired), and then request the fresh token. Does that make sense? Obviously with the sliding auth window this is not necessary (which is partly why it seems like a good idea!) – arcologies Feb 10 '17 at 18:21
  • Sending the expiration to the client can indeed convey information on when to request a new token. But it should never be used in such a way the client can change it. In the case of JWT that cannot be done and that is indeed an alternate approach. As you are the sole user of your API it is of course up to you how to deal with expiring tokens. You need to do something in any case. But would it be easier to periodically request a new token. Keeps everything nice and separated. – harm Feb 10 '17 at 18:28