title: JWT authentication with Vue.js
body: <p>I'm working on an SPA with Vue.js and vue-router and I'm now dealing with authorization/authentication using JWT. I have the back end (API endpoint) sorted out, such that it will issue a token in response to a login and check for the requisite header on subsequent requests. I now want to implement the client (Vue.js) side.</p>
  
  <p>As I understand it, fundamentally what I need to do is to require authentication for all routes apart from '/' and '/login'. If authentication is present then I submit the token (which is stored in localStorage after a successful login) in an Authorization header. If it fails to validate successfully on the server, then the user will be redirected to '/login' as a result of the error response. </p>
  
  <p>So, I have a couple of questions about what I need to do to implement this:</p>
  
  <ol>
  <li><p>How do I best submit a header with every request, apart from to the login endpoint? I know with JQuery, which I'm using for AJAX, I can configure a global 'ajaxSetup' which will cause the header to be submitted with each request, but how can I specify exceptions? It's cumbersome to individually add the header to each API endpoint request.</p></li>
  <li><p>Similarly, how to I set up an authentication pre-check which applies to all routes apart from the 2 mentioned ('/' and '/login')?</p></li>
  <li><p>Given that I'm using the presence or otherwise of apparently valid authentication (apparently because it still has to be validated on the API endpoint) to determine whether or not to show certain menu items, etc., is it feasible to make this more granular and show different things for different permission levels, as determined by the 'scope' field in the token payload? Clearly the simplest way of dealing with a JWT token is purely to determine whether it is present or not, so no parsing of content is required at the client end. But given that JWT does allow meaningful content, is it a bad idea to try to make use of that meaning on the client side as well as server? Obviously this becomes less practical if the token is itself encrypted, so my idea would be to use unencrypted tokens (and ensure nothing of any consequence is exposed in the payload). </p></li>
  </ol>