title: Alternate approaches to token based authentication
body: <p>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:</p>
  
  <ol>
  <li>User auths by providing user/pass, receives back a token and expiration</li>
  <li>Until , token is passed with every request</li>
  <li>Upon expiration, a new token is requested (either by providing a separate 'refresh' token or just by re-authenticating with user/pass)</li>
  </ol>
  
  <p>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).</p>
  
  <p>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).</p>