JWT Auth [Backend]

Обучающее видно по JWT - https://youtu.be/fN25fMQZ2v0

Frontend часть проекта - https://itbooster.ru/pet-projects/5/details/

1. Цель проекта

Реализовать систему аутентификации и авторизации по email и паролю с использованием JWT access и refresh токенов:

• Хранение пользователей в БД (PostgreSQL / MySQL / MongoDB — по выбору).

2. Функциональные требования

2.1. Регистрация пользователя

• Пользователь вводит:

  • email

  • password

  • (опционально) name

• Проверки:

  • email уникален,

  • пароль валидный (минимальная длина, сложность).

• Пароль хранится в БД в захэшированном виде (bcrypt / argon2).

• После успешной регистрации:

  • вернуть сообщение об успехе или сразу выдать пару токенов (access + refresh) — оговорить поведение.

2.2. Логин пользователя

• Эндпоинт принимает:

  • email

  • password

• При успешной аутентификации:

  • сгенерировать accessToken (короткая жизнь, 5–15 минут),

  • сгенерировать refreshToken (долгая жизнь, 7–30 дней),

  • вернуть:

    • accessToken в JSON (в теле ответа),

    • refreshToken:

      • либо в JSON,

      • либо в HttpOnly Secure cookie (предпочтительно с точки зрения безопасности).

• При неверных данных вернуть 401 с общим сообщением вида Invalid credentials.

2.3. Обновление access токена (refresh)

• Эндпоинт /auth/refresh:

  • принимает refreshToken:

    • из тела запроса,

    • или из HttpOnly cookie.

• Проверяет:

  • подпись и срок действия refresh токена,

  • что токен не отозван/не заблокирован (через хранилище refresh токенов или токен-версий).

• При успехе:

  • выдать новый accessToken,

  • опционально новый refreshToken (ротация).

• При неуспехе:

  • вернуть 401 и удалить refresh cookie (если используется cookie).

2.4. Logout (выход)

• Эндпоинт /auth/logout:

  • на стороне backend:

    • либо помечает refreshToken как недействительный (черный список / версия токена в БД),

  • на стороне frontend:

    • удалить accessToken из памяти/хранилища,

    • удалить refreshToken или очистить HttpOnly cookie (через Set-Cookie с истёкшим сроком).

2.5. Доступ к защищённым ресурсам (авторизация)

• Все защищенные API-роуты требуют заголовок:

  • Authorization: Bearer <accessToken>

• Backend:

  • валидирует access токен (подпись, срок),

  • извлекает из payload:

    • userId,

    • roles / permissions (если нужны).

• При валидном токене:

  • добавить данные пользователя в req.user,

  • передать запрос дальше.

• При невалидном:

  • вернуть 401 (Unauthorized).

2.6. Роли и права (опционально)

• Добавить поле role в модель пользователя (например: USER, ADMIN).

• Реализовать middleware/guard, который проверяет наличие нужной роли для определённых маршрутов.

3. API (черновой контракт)

POST /auth/register

Request (JSON):

{
  "email": "user@example.com",
  "password": "string",
  "name": "Optional Name"
}

Response (200/201):

{
  "message": "User registered successfully"
}

(или сразу accessToken + refreshToken — по решению).

POST /auth/login

Request (JSON):

{
  "email": "user@example.com",
  "password": "string"
}

Response (200):

{
  "accessToken": "jwt-access-token",
  "refreshToken": "jwt-refresh-token"
}

Либо:

• accessToken в JSON,

• refreshToken — только в HttpOnly cookie.

POST /auth/refresh

Request:

• Либо:

  javascript

  { "refreshToken": "jwt-refresh-token" }
  

• Либо чтение refreshToken из cookie.

Response (200):

{
  "accessToken": "new-jwt-access-token"
}

Опционально:

{
  "accessToken": "new-jwt-access-token",
  "refreshToken": "new-jwt-refresh-token"
}

POST /auth/logout

• Без тела или с refreshToken.

• Ответ:

{ "message": "Logged out successfully" }

Пример защищённого эндпоинта

GET /user/profile

• Требует заголовок Authorization: Bearer <accessToken>.

• Ответ (200):

{
  "id": 1,
  "email": "user@example.com",
  "name": "User Name"
}