Процесс аутентификации пользователя во фронтенд-приложении в общем виде состоит из следующих шагов:
- Запрос учетных данных: Пользователь вводит логин и пароль в форму на сайте или в приложении.
- Отправка данных на сервер: Фронтенд отправляет эти данные на сервер (бэкенд) с помощью HTTP-запроса (обычно
POST) на специальный эндпоинт аутентификации. Данные могут быть отправлены в теле запроса в формате JSON или FormData.
- Проверка данных на сервере: Бэкенд получает данные, проверяет их на наличие в своей базе данных (например, соответствует ли логин существующему пользователю и совпадает ли хэш введенного пароля с хэшем пароля в базе).
- Генерация токена/сессии: Если учетные данные верны, сервер генерирует уникальный маркер аутентификации. Это может быть:
- Сессионный ID: Сервер создает сессию и связывает ее с пользователем, отправляя клиенту идентификатор сессии (например, в куке с флагом
HttpOnly).
- Токен (например, JWT): Сервер генерирует токен, содержащий информацию о пользователе и его правах, подписывая его своим секретным ключом. Этот токен отправляется клиенту.
- Отправка токена/сессии клиенту: Сервер отвечает фронтенду, отправляя сгенерированный маркер аутентификации.
- Если используется сессионный ID, он обычно передается в HTTP-заголовке
Set-Cookie.
- Если используется токен, он может быть передан в теле ответа (JSON) или в заголовке
Authorization (например, Bearer <токен>).
- Сохранение маркера на клиенте: Фронтенд получает маркер и сохраняет его для последующих запросов.
- Сессионный ID хранится в браузере в куках (автоматически).
- Токен может храниться в localStorage, sessionStorage или куках (с флагом
HttpOnly для защиты от XSS). Предпочтительнее использовать HttpOnly куки для токенов доступа, так как это снижает риск кражи токена через XSS-атаки. Для JWT также может храниться токен обновления в HttpOnly куках.
- Использование маркера для защищенных запросов: При выполнении последующих запросов к защищенным ресурсам (требующим аутентификации), фронтенд отправляет сохраненный маркер в каждом запросе.
- Для сессий браузер автоматически отправляет соответствующие куки с сессионным ID.
- Для токенов фронтенд должен явно добавлять токен в заголовок
Authorization (например, Authorization: Bearer <токен>).
- Проверка маркера на сервере: При получении каждого запроса к защищенному ресурсу, сервер извлекает маркер из запроса и проверяет его подлинность (например, срок действия токена, подпись токена, наличие сессии с таким ID).
- Авторизация: Если маркер действителен, сервер определяет пользователя, связанного с этим маркером, и проверяет его права доступа к запрашиваемому ресурсу (это уже процесс авторизации, следующий за аутентификацией).
- Выполнение запроса: Если пользователь аутентифицирован и авторизован, сервер в