Not Vue specific, but I would put some thought into if you really need to jump on the JWT bandwagon.
If a user needs to destroy a session remotely (sign in out of all devices for example), you’d have to implement something that would hit a database for each request to check the validity of the token. This in turn basically destroys the usefulness of storing all the authenticate parameters and authorization in the token in the first place. You might as well store what you would store in a JWT in a database, that way the user has fine grain control over their sessions.
You might ask where JWTs would be useful if not client->server in web applications, and the answer would most probably be services (mostly internal), where the tokens do not store or identify a session, but rather one off bang.
It certainly depends on your application, and you may not care that much in the first place, but if you do decide to implement fine-grained session control, I’d steer away from JWT.
Edit: I thought I’d add a couple more reasons.
You’ll be sending the JWT for each authenticated request, and depending on how much information is in the JWT, that will start to add up over time (extra bytes in the header).
Edit as response to your question below as I’ve reached the post limit for a new user:
Sure. OAuth is a way of implementing an authentication system. JWTs are not an authentication system, they have just been used as a way of storing the session created by authenticating.
The idea behind JWTs is valid, where you don’t need to store them on the server to check their validity. Only a server with the secret can create a valid token, and then validate it, meaning you don’t have to store state on a server. This is important because if you are attempting to scale horizontally (more servers) and you are storing sessions on a server without sharing them with a database, you’ll run into problems as the load balancer generally will fire each request to a server with less load. Who’s to tell if that server you just stored the user who signed in on will be the server the next request for that user goes to? Now there are methods around this, on different levels…
- On the load-balancer you can use hash lookups to ensure the user always reaches the same server, but this method has problems such as; what if that server goes down?
- You can store the session state on the client side with methods like JWTs. However now, as I listed above, you lose control over important aspects you may consider important in the future, like invalidating a session. If you decide to implement JWT checking with a database, congratulations! because at this stage, you might as well store the session in the database anyways.
- Storing the state in the database, you have control over the session, no nasty techniques like blacklisting JWTs with Redis, and invalidating a session is as easy as deleting it.
OAuth dictates a number of ways a process of authentication should flow, for example; Implicit, Credentials, Authorization Code etc. Just as a side note you’ll find these flows, although well defined, aren’t always honoured to the complete spec even by larger companies.
There are quite a few resources you can find with google about authentication and authorization however I can give you a small example.
- User makes a request to the server
POSTing their credentials over
HTTPS and on a successful match, gets returned a session ID in the form of a HTTP only cookie. This session ID could represent a record in a database (postgres, redis, etc), with record containing the details for the session. For example when it should expire, scopes the session has (access control), or meta data like when it was created and the user agent.
- User makes a request to an API, the API checks the
Origin header of the request (
CORS to prevent
CSRF), and retrieves the session via the ID from the
Cookie header. If the session exists the session could be checked further if needed, for example, the
User-Agent, and the request could continue if it was valid!
Now this is a simple example, and your application may as well not need it, however, it keeps you in control of the session storage, as well as being suitable for scaling horizontally when the time comes. You’ll find that Vue doesn’t care about how you authenticate, so really implement it how you will. There are well trodden methods, and Vue can work smoothly with pretty much all of them.
By all means, you can use JWTs, just my two cents on the matter.
Have a check out of https://www.owasp.org/ it has some good resources on what is good and bad.