1. Что такое JWT token

JWT token (он же JSON Web Token) - это строка, состоящая из трех частей: заголовок, данные и подпись.

Посетитель сайта хочет прочитать свою переписку. Он заходит на страницу с диалогами, и сайт отправляет запрос на получение контента (списка сообщений), при этом к запросу прикрепляется специальная строка - JWT токен. С помощью этой строки сервер проверяет, авторизован ли пользователь, и решает, направить ли ему в ответ контент сайта (список сообщений).

Существует два вида JWT-токенов: access-token и refresh-token, которые создаются и используются только в паре. Эту пару токенов генерирует сервер и выдает конкретному пользователю в ответ на запрос авторизации. При этом каждому из токенов назначается "срок жизни" - период времени, в течение которого токен будет распознаваться бекендом как валидный. Для этого сервер сохраняет выданную пару токенов в своей базе данных, а при новой авторизации заменяет у себя информацию о токенах и их валидности токенов.

1.1. Access-токен

Особенностью access-токена является то, что он хранится локально на frontend-части сайта в localStorage, и его необходимо каждый раз записывать в заголовки запросов на бекенд.

С помощью access-токена мы получаем доступ к функциям сайта, которые зависят от бекенда (получают данные от бекенда). Это, в основном данные для страниц, доступных авторизованным пользователям ( список сообщений, возможность оставить комментарий, удалить свой пост).

Это работает следующим образом: пользователь нажимает кнопку "загрузить историю сообщений". Сайт генерирует GET-запрос на бекенд, добавляет в headers запроса данные Access-токена. Бекенд, соответственно, считывает заголовки, проверяет валидность токена и направляет пользователю ответ со списком сообщений, который доступен только авторизованным пользователям.

1.2. Refresh-токен

Когда у access-токена заканчивается срок действия, на помощь приходит refresh-токен.

Этот токен отличается тем, что хранится в cookies, и поэтому всегда автоматически прицепляется к запросам на бекенд.

С помощью refresh-токена мы обновляем устаревший ("протухший") access-токен. Для этого мы отправляем запрос на специальный endpoint бекенда (обычно "/api/refresh"), а в ответ сервер генерирует новую пару access token + refresh token.

Далее цикл повторяется: сервер сохраняет информацию о новой валидной паре access-token + refresh-token, а сайт прикрепляет новый access-token к заголовкам новых запросов.

Если до сих пор не понятно, есть очень крутой и понятный ролик на ютуб?.

2. Авторизация через JWT token (теория)

Авторизация с использованием JWT token реализуется с помощью двух основных паттернов:

• первичная авторизация (т.е. когда пользователь первый раз зашел на сайт, либо когда пользователь последний раз авторизовался очень давно, и пара JWT-токенов устарела)

• авторизация через обновление токена (т.е. когда пользователь авторизовался на сайте, затем закрыл вкладку, сбросив хранящееся в переменной состояние isAuth, и далее заново открыл вкладку с сайтом; но при этом пара JWT-токенов либо refresh-токен не успели устареть)

2.1. Авторизация с нуля (первичная авторизация )

• Посетитель переходит на страницу авторизации http://my_awesome_web_app.com/login.

• Посетитель вводит логин и пароль в форму авторизации, и нажимает кнопку "Авторизоваться" ("Login").

• Запрос авторизации с введенными ранее логином и паролем отправляются на сервер.

• Сервер проверяет, есть ли такая пара логин + пароль в его базе данных с пользователями.

• Если такой пользователь не найден, сервер отправляет в ответ ошибку.

• Если логин и пароль введены верно, сервер генерирует для пользователя пару токенов access token + refresh token, и сразу же записывает refresh токен в httpOnly cookie.

• Далее сервер создает ответ об успешной авторизации, и записывает в body ответа сгенерированный access token. Ответ направляется пользователю.

• Сайт принимает ответ сервера и записывает access token из ответа в свой localStorage. Также для целей доступа пользователя к приватным страничкам сайт создает и устанавливает переменную isAuth = true.

• Далее ко всем запросам пользователя добавляется access token, и сервер дает ответ пользователю как авторизованному (например, сервер считывает из accessToken id пользователя и может дать ему список его друзей или его сообщений).

2.2. Авторизация через обновление токена

• Посетитель переходит на любую страницу сайта http://my_awesome_web_app.com/news.

• Если для просмотра страницы http://my_awesome_web_app.com/news не требуется авторизация, сайт показывает эту страничку.

• Если для просмотра страницы http://my_awesome_web_app.com/my_messages нужна авторизация, сайт показывает нам "крутилку", и в это время пытается обновить авторизацию на основе ранее полученных токенов.

• Сайт пробует считать access токен из localStorage, и направить запрос на получение данных пользователя (аватарки, имени пользователя и т.п.).

  • Если access token окажется валидным, то с сервера в ответ придут данные пользователя, и сайт может установить переменную isAuth = true. Далее, соответственно, пользователь перенаправляется на страничку, которую изначально хотел посмотреть.

  • Если access token окажется невалидным, то с сервера в ответ придет ошибка. Эту ошибку нужно перехватить и попробовать обновить авторизацию через refresh token. То есть в тот момент, когда пришел ответ с ошибкой, перехватить ошибку и направить запрос на адрес "/api/refresh". К этому запросу автоматически прицепляется cookies с refresh-токеном.

    • При успешном обновлении авторизации сервер выдает пользователю новую пару access token + refresh token, и далее пользователь сможет сделать успешный запрос за получением данных пользователя, и, соответственно, статуса isAuth = true на сайте. Далее, соответственно, пользователь перенаправляется на страничку, которую изначально хотел посмотреть.

    • При неудачной попытке обновления авторизации, устанавливается переменная isAuth = false, и пользователь перенаправляется на страницу авторизации, либо на домашнюю страницу сайта.

• В результате, пользователь получает желаемую страничку, либо перенаправляется на страницу авторизации.

3. Что требуется для JWT авторизации на frontend

3.1. Создать проект

Введите в консоли: npx create-react-app jwt-auth-app

3.2. Настроить axios

Введите в консоли: npm install axios

В папке src/ создадим файл api.config.js, в котором пропишем для axios добавление accessToken к запросам и обновление токенов при невалидном accessToken.

import axios from "axios";

export const instance = axios.create({
  // к запросу будет приуепляться cookies
  withCredentials: true,
  baseURL: "https://jsonplaceholder.typicode.com/",
});


// создаем перехватчик запросов
// который к каждому запросу добавляет accessToken из localStorage
instance.interceptors.request.use(
  (config) => {
    config.headers.Authorization = `Bearer ${localStorage.getItem("token")}`
    return config
  }
)


// создаем перехватчик ответов
// который в случае невалидного accessToken попытается его обновить
// и переотправить запрос с обновленным accessToken
instance.interceptors.response.use(
  // в случае валидного accessToken ничего не делаем:
  (config) => {
    return config;
  },
  // в случае просроченного accessToken пытаемся его обновить:
  async (error) => {
   // предотвращаем зацикленный запрос, добавляя свойство _isRetry 
   const originalRequest = {...error.config};
   originalRequest._isRetry = true; 
    if (
      // проверим, что ошибка именно из-за невалидного accessToken
      error.response.status === 401 && 
      // проверим, что запрос не повторный
      error.config &&
      !error.config._isRetry
    ) {
      try {
        // запрос на обновление токенов
        const resp = await instance.get("/api/refresh");
        // сохраняем новый accessToken в localStorage
        localStorage.setItem("token", resp.data.accessToken);
        // переотправляем запрос с обновленным accessToken
        return instance.request(originalRequest);
      } catch (error) {
        console.log("AUTH ERROR");
      }
    }
    // на случай, если возникла другая ошибка (не связанная с авторизацией)
    // пробросим эту ошибку 
    throw error;
  }
);

• Введите в консоли: npm install axios

В папке src/ создадим файл api.auth.js, в котором пропишем запросы на backend:

import { instance } from "./api.config.js";

export default const AuthService {

    login (email, password) {
        return instance.post("/api/login", {email, password})
    }
    
    refreshToken() {
        return instance.get("/api/refresh");
    }
    
    logout() {
        return instance.post("/api/logout")
    }
}

4. Создаем Private Routes

На многих сайтах существует два вида страниц: с общим доступом и приватные.

Страницы с общим доступом может открыть любой посетитель сайта (например, новости, информация о компании, а также страница авторизации).

Приватные страницы доступны только авторизованным пользователям, иначе они автоматически отправляют неавторизованного посетителя на страницу авторизации.

Для того, чтобы сайт знал, авторизован ли пользователь, необходимо хранить эту информацию в двух глобальных переменных: isAuth, isAuthInProgress.

4.1. Установим React Router

Введите в консоли: npm install react-router react-router-dom

4.2. Создадим переменные isAuth, isAuthInProgress

Эти переменные можно создать и хранить в state-менеджере (redux, mobX), можно создать специальный AuthContext, также можно хранить их в useState, либо создать хук, который будет обновлять авторизацию и возвращать объект с указанными переменными.

Разберем это на примере хранения переменных в mobX.

Введите в консоли: npm install mobx mobx-react-lite

В папке src/ создадим файл store.js, в котором пропишем указанные переменные.

import { makeAutoObservable } from "mobx";
import AuthService from "./api.auth.js";

class AuthStore {   
  isAuth = false;
  isAuthInProgress = false;
  
  constructor() {
    makeAutoObservable(this, {}, { autoBind: true });
  }

  async login(email, password) {
    this.isAuthInProgress = true;
    try {
      const resp = await AuthService.login(email, password);
      localStorage.setItem("token", resp.data.accessToken);
      this.isAuth = true;

     } catch (err) {
      console.log("login error");
     } finally {
      this.isAuthInProgress = false;
    } 
  }

  async checkAuth() {
    this.isAuthInProgress = true;
    try {
      const resp = await AuthService.refresh();
      localStorage.setItem("token", resp.data.accessToken);
      this.isAuth = true;

     } catch (err) {
      console.log("login error");
     } finally {
      this.isAuthInProgress = false;
    } 
  }

  async logout() {
    this.isAuthInProgress = true;
    try {
      await AuthService.logout();
      this.isAuth = false;
      localStorage.removeItem("token");
    } catch (err) {
      console.log("logout error");
    } finally {
      this.isAuthInProgress = false;
    } 
  }
  
}

export default new AuthStore();

4.3. Создадим HOC PrivateRoute

В папке src/ создадим файл privateRoute.jsx, в котором пропишем логику privateRoute:

• если процесс авторизации не завершен, то ждем, когда сервер пришлет ответ об удачной/неудачной попытке авторизации

• если пришел ответ от сервера, и авторизация успешна, тогда показываем пользователю запрошенную приватную страничку

• если пришел ответ от сервера, но авторизация неуспешна, то перенаправляем пользователя на страницу авторизации

import { Navigate, Outlet, Route } from "react-router-dom";
import authStore from "./store.js";
import { observer } from "mobx-react-lite";

const PrivateRoute = (props) => {

  if (authStore.isLoadingAuth) {
    return <div>Checking auth...</div>;
  }
  if (authStore.isAuth) {
     return <Outlet/>
  } else {
    return <Navigate to="/login" />;
  }
};
  
export default observer(PrivateRoute);

В папке src/ редактируем файл App.jsx, в котором добавим приватные роуты.

import React, { useEffect } from "react";
import { Route, Routes, BrowserRouter } from "react-router-dom";
import { observer } from "mobx-react-lite";
import AuthStore from "./store.js";
import PrivateRoute from "./privateRoute.js";
 
import LoginPage from "./pages/loginPage";
import UsersPage from "./pages/usersPage";

const App = observer(() => {
  
  useEffect(() => {
     AuthStore.checkAuth();
  }, []);
 
  return (
    <BrowserRouter>
        <Routes>
    //страница, для посещения которой авторизация не требуется
            <Route path="/login" element={<LoginPage />} />

    //страницы, для посещения которых требуется авторизация
            <Route path="/users" element={<PrivateRoute  />}>
                <Route path="" element={<UsersPage />} />
                <Route path=":id" element={<UserPage />} />
            </Route>

            <Route path="*" element={<div>404... not found </div>} />
        </Routes>
    </BrowserRouter>
   );
});

export default App;

Успех!

Вот и готова первая JWT-авторизация на фронтенде. Всем работающего кода, даже когда у тебя лапки ?