title: RESTful authentication. Client-side, stateless unauthentication
body: <p>I'm implementing a set of RESTful services for some developments and one of these is an <strong>authentication service</strong>.</p>
  
  <p>This <strong>authentication service</strong> authenticates two kinds of identities:</p>
  
  <ul>
  <li><strong>Applications</strong>. <em>AppKey-based authentication so clients must register for a key in order to access to the rest of the services</em>.</li>
  <li><strong>Users</strong>. <em>Well-known credentials (user+password)-based user authentication so humans and machines can work with these RESTful services through client applications.</em></li>
  </ul>
  
  <p>These RESTful services <strong>are <em>stateless</em></strong>.</p>
  
  <p>When a client application authenticates against the <strong>authentication service</strong>, or when a human or machine authenticates as an identity using credentials, both operations generates an <strong>AppToken</strong> and <strong>UserToken</strong> respectively.</p>
  
  <p>These tokens are a salted hash so subsequent requests to the RESTful infrastructure will be authenticated without sharing <em>AppKeys</em> and <em>credentials</em>.</p>
  
  <p>Form the point of view of a fully stateless approach, these tokens should be stored no where in the service layer but in some kind of client-side state (f.e., a Web client would store it using <em>HTTP cookies</em>). <strong>This is how my current implementations are working right now</strong>.</p>
  
  <p>Because re-authenticating each request using these <em>tokens</em> and let the service layer receive the token coming from the client so it can compare <em>what token comes from the client</em> and <em>check if it's a valid token re-generating it in the service layer and compare with the one owned by the client</em> is too expensive, I've implemented a service layer <strong>AppToken</strong> and <strong>UserToken</strong>, both having an expiration date and an owner (the application or user for which the token have been created for), in order to check if the token coming from the client exists in the token store.</p>
  
  <p><em>How does clients interactively unauthenticate?</em> <strong>Just dropping client-side security state</strong>. If it's a Web client, it drops the authentication cookie and just refreshing the page, client detects no authentication cookie and user is redirected to the login page.</p>
  
  <p>From the point of view of RESTful services, <em>this is a stateless unauthentication</em>: clients aren't aware about the <em>trick</em> of having a service layer pseudo-authentication state. <strong>It's just a service implementation detail - a performance optimization -.</strong></p>
  
  <p>I'm not going to list the <em>pros</em> of stateless services because I'm absolutely sure that this approach is the way to go, but I find a problem: <strong>stateless authentication/unauthentication means that clients don't notify server that they close their session, so the security store ends with a lot of useless records</strong>.</p>
  
  <p>This isn't a great problem if service clients are ones that would have limited time sessions (f.e., 1 hour, 3 hours, a day...), but <strong>what happens if an user must be authenticated <em>forever (8 months, a year)</em>?</strong>. <strong>How do you distinguish <em>what's an an expired token?</em></strong></p>
  
  <p>There're some approaches in order to solve this situation:</p>
  
  <ol>
  <li><p><strong>Whenever the service layer receives a request, it updates token expiration date, so an automated process may drop those tokens that have expired defining an arbitrary expiration of tokens (f.e. 24 hours)</strong>.</p></li>
  <li><p><strong>Compromise stateless nature of the architecture and let clients notify service layer that they don't want to be authenticated anymore, so service can drop the associated token to the client session</strong> (<em>But wait... what happens if client closes a Web client? User will never actively notify service that the token must be dropped... So... Zombie tokens are there yet, so an automated process should drop them, but... what's a zombie token? <strong>I don't like this approach</strong>)</em>.</p></li>
  <li><p><strong>Completely stateless authentication, no store, per-request authentication.</strong></p></li>
  </ol>
  
  <p><strong>This is the question! What's your suggested approach - even if it's not 1., 2. or 3. - and why?</strong></p>
  
  <p>Thanks for this long reading - I honestly believe that question's conclusions are going to be extremely useful to anyone -!</p>