SPA authentication?

Question

Vue.js

Hello. And how to properly implement authentication on the client. Well, make a form, send a POST request from it, get a response, save the response to a variable. And already, depending on the change, have access to one or the other components? Or what's right?
Thanks?

Answer 1

JWT

Answer 2

Using a JWT and storing it in storage is not safe.
https://www.rdegges.com/2018/please-stop-using-loc...
It's still preferable to use cookies. MDN details how to use them to store sessions .
From the Vue side, everything is quite simple:
1. We create a variable in store and store the state of the presence of the installed cookie in it.
2. To separate access to routes, we use guard, like this:

const authGuard = (to, from, next) => {
  if (store.getters.isAuthenticated) {
    next();
    return;
  }
  next('/login');
}

const router = new Router({
  routes: [
    {
      path: '/',
      name: 'Home',
      component: Home,
    },
    {
      path: '/account',
      name: 'Account',
      component: Account,
      beforeEnter: authGuard,
    },
});

3. At the end of the session, delete the cookie.

Answer 3

As Sergei Gornostaev already answered you, use JWT for this, only you can enter data into it, for example, the following: session identifier for the user or his id (depending on the security of the application), lifetime, session extension token, lifetime of the authorization extension token, issued rights (analogous to permissions in OAuth)
Thus, for each subsequent request that requires authorization, send an additional Authorization: Bearer header. You can save this JWT either in session storage or in local storage (also depending on the purpose) and renew it with a separate request at the end of its life but during the lifetime of the renewal token. Or generally refuse to renew and issue on a temporary basis, and if it has ended, then request authorization again.
You can check the issued permissions for a particular action at 2 levels: server (required), client (desirable).

Answer 4

JWT.
Store the token in some browser storage.
To share access on the client, in the case of vuejs, you can write a custom directive that will validate the token and render or not render the checked component.

Answer 5

You have already been advised JWT. Great thing, you can store some information in a token (only, of course, you can’t trust it). I just don't recommend using cookies unless it's absolutely necessary. The fact is that the browser stores cookies in clear text in the file system, and encrypts the local storage. Well, reading / writing to storage is much easier than to cookies. Not without nuances, but easier.
In short, you send form data to the server and receive a token in response. You put this token in a service that writes it to storage at the same time. For each request, add a token to the header. When you first load the application, check if there is a token in the store and if there is, directly write it to the service.
It remains only to decide for yourself the degree of protection.
Basically, there are 3 types of severity
1. The token is stored in storage/memory, but you never trust it, and before you put it on any route, send it to the server for verification. In most cases, this approach is redundant
2. Create a root route for authorization and implement token verification on the server only at the level of this route, all "closed" routes are children of this route and thus you close all routes and get rid of requests that are redundant in most cases. The disadvantages of this approach may appear when the token "goes out".
3. You don't validate the token on the server at all. In this case, it doesn't matter for performance whether you close only one parent route or all of them. The disadvantages are the same as for option 2, but there are more areas for manifestation.
That is, if the user remained inactive on the page on a closed route for a long time and the token is rotten, then the user can still go to any route and there will be no check for option 2. But if the user reloads the page, the check will be. In the third case, the check will always be.
At first glance, it may seem that option 1 is not even redundant, but in most cases, the transition to each route will be accompanied by a request to the server to upload data, so de facto authorization will still take place. The main thing is not to forget to process 401
Well, do not forget to also close the authorization route for already authorized users with the same check, just the other way around)
Yes, note that there is not a word about vue here, because this general principle applies to all modern frameworks.