Зачем нужны логин и пароль при использовании JWT токенов

Да, на одном сайте обычно сочетают вход по логину и паролю с JWT: логин‑пароль используют для первичной аутентификации, а JWT или сессионный идентификатор в cookie — для последующих запросов. Для браузера чаще выдаётся httpOnly‑cookie с сессией, а для SPA и мобильных клиентов — JWT в заголовке Authorization или тоже в cookie. Таким образом один и тот же сервер может одновременно обслуживать разные типы клиентов разными форматами токенов.

Нужно разделять два уровня: (1) чем пользователь подтверждает личность при входе (логин‑пароль, OAuth, SSO и т.п.) и (2) в каком виде сервер хранит факт аутентификации между запросами (сессионный идентификатор в cookie или токен, например JWT). Логин‑пароль — это только способ первичной аутентификации, а JWT или обычный session_id — это сессионный слой, по которому сервер узнаёт пользователя в дальнейшем.

В одном приложении без проблем уживаются обе схемы. Браузер может работать через httpOnly‑cookie с сессионным идентификатором (классическая серверная сессия), а внешние клиенты (SPA, мобильные приложения, интеграции) — через JWT, который они отправляют в заголовке Authorization: Bearer <token> или который сервер также кладёт в httpOnly‑cookie. Форма логина при этом может быть одна и та же: пользователь вводит логин и пароль, а уже сервер, исходя из типа клиента или маршрута, решает, какой токен выдать и куда его положить.

Типичный поток аутентификации в такой смешанной схеме может выглядеть так:

• Пользователь (или клиентское приложение) отправляет логин и пароль на эндпоинт /login по HTTPS.
• Сервер проверяет учётные данные и при успехе создаёт либо сессию в хранилище и кладёт её идентификатор в httpOnly‑cookie, либо формирует JWT с полями вроде sub или user_id, ролями и временем жизни.
• Для классического веб‑интерфейса (server‑side rendering) удобнее использовать cookie‑сессию: при каждом запросе браузер сам отправляет cookie, сервер по session_id находит пользователя и его права.
• Для SPA и мобильных приложений часто используют JWT: после логина клиент получает токен (из тела ответа или из cookie) и затем сам явно прикрепляет его к запросам, обычно в заголовке Authorization.
• Все последующие запросы выполняются уже без повторной отправки пароля: сервер читает cookie или JWT, валидирует токен (подпись, срок действия) и на этой основе аутентифицирует пользователя.
• Для безопасности нередко применяют пару: короткоживущий access-JWT + более долгоживущий refresh-токен (часто в httpOnly‑cookie), чтобы можно было прозрачно обновлять access‑токен без повторного ввода логина и пароля.

Итого: логин‑пароль — это шаг входа, а JWT и/или сессионный идентификатор в cookie — механизм поддержания аутентифицированного состояния. Ничто не мешает одному сайту одновременно использовать httpOnly‑cookie с флагами Secure и SameSite для браузера и JWT для внешнего API или мобильных клиентов, используя общий механизм логина и единые правила авторизации.