title: Are JWTs a secure option for user authentication?
body: <p>I like the simplicity of JWTs and just used them when implementing an authentication mechanism for an web app where I have an Elixir/Phoenix backend that serves a RESTful JSON API and an Angular 2 frontend.</p>
  
  <p>Today I stumbled about <a href="http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/" rel="nofollow">this</a> article (I'm in no way affiliated with this website) and it gave me some doubts about the use of JWT which I would like to discuss. Mainly:</p>
  
  <ul>
  <li>There is no real way of JWTs to be invalidated without shutting down
  the whole system. At least when they are stateless. </li>
  <li>That means you cannot revoke access, which could be very bad.   </li>
  <li>LocalStorage - where JWTs are mostly stored on the front-end side - is not as secure as Session Storage.</li>
  </ul>
  
  <blockquote>
    <p>Local storage, unlike cookies, doesn’t send the contents of your data
    store with every single request. The only way to retrieve data out of
    local storage is by using JavaScript, which means any attacker
    supplied JavaScript that passes the Content Security Policy can access
    and exfiltrate it. Not only that, but JavaScript also doesn’t care or
    track whether or not the data is sent over HTTPS. As far as JavaScript
    is concerned, it’s just data and the browser will operate on it like
    it would any other data.</p>
    
    <p>After all the trouble those engineers went through to make sure nobody
    is going to make off with our cookie jar, here we are trying to ignore
    all the fancy tricks they’ve given us. That seems a little backwards
    to me.</p>
  </blockquote>
  
  <p>So far I think his points are not valid - as long as one serves everything via https and protects against XSS and CORS attacks. I mean if malicious JS can be executed on the site this is really not a problem of JWT. And JS does not allow mixed content (http and https).</p>
  
  <p>For invalidating all tokens: Just use something like a JWT generation-number variable, that could live in your environment variables and is encoded in every token. It is a simple integer. If you want to invalidate all tokens, increment it. Then you just need a mechanism to check if the generation number matches. This doesn't have to hit the DB and shouldn't be a performance issue. And it shouldn't be too difficult to roll this out over multiple instances with a solid deployment strategy.</p>
  
  <p>For invalidating a single token: Use refresh tokens and a very short lifespan for a JWT (couple of minutes). If the TTL of the JWT is almost over, the user get's a new one via the refresh token. This means a DB hit every couple of minutes.</p>
  
  <p>Or am I mistaken?</p>