Где передаются данные аутентификации в HTTP-запросах?

Веб-приложениям необходимо идентифицировать пользователя при каждом запросе к защищённым ресурсам. Для этого данные аутентификации передаются от клиента (браузера или другого клиента) к серверу. Основные места их передачи — это заголовки HTTP, тело запроса и, реже, параметры URL.

Основные способы передачи

• Заголовок Authorization: Это стандартный и рекомендуемый способ для API. Формат: Authorization: <Тип> <Данные>. Например, для JWT-токена: Authorization: Bearer eyJhbGciOiJIUzI1NiIs....
• Куки (Cookies): После успешного входа сервер устанавливает cookie (например, sessionid), которую браузер автоматически прикрепляет к каждому последующему запросу в заголовке Cookie. Это классический подход для веб-сайтов с сессиями.
• Тело запроса (Body): При первоначальной аутентификации (логине) данные (логин/пароль) обычно отправляются в теле POST-запроса, часто в формате JSON или application/x-www-form-urlencoded.
• Параметры запроса (Query Parameters): Передача токена в URL (например, ?token=abc) крайне не рекомендуется, так как URL может попасть в логи сервера и историю браузера.

Пример кода (клиентская отправка)

Вот как может выглядеть отправка аутентифицированного запроса с использованием JavaScript (Fetch API):

// Использование Bearer токена в заголовке Authorization
const token = 'your_jwt_token_here';
fetch('https://api.example.com/protected-data', {
    method: 'GET',
    headers: {
        'Authorization': `Bearer ${token}`,
        'Content-Type': 'application/json'
    }
})
.then(response => response.json())
.then(data => console.log(data));

// Запрос с куками отправляется автоматически браузером,
// если куки установлены для домена api.example.com.

Где что применяется?

• SPA и мобильные приложения (API): Используют преимущественно заголовок Authorization с Bearer-токенами (JWT, OAuth).
• Традиционные серверные веб-приложения: Работают на основе сессий, хранящих идентификатор в cookie.
• Базовая аутентификация (Basic Auth): Также использует заголовок Authorization, но в формате Basic <base64(login:password)>. Сейчас применяется редко, в основном в простых сценариях или внутренних системах.

Вывод: Для современных API и одностраничных приложений предпочтительным методом является передача токена в заголовке Authorization. Для классических веб-сайтов с серверным рендерингом удобно использовать сессионные куки. Ключевое правило — никогда не передавайте чувствительные данные аутентификации (особенно долгоживущие токены) через URL из-за рисков безопасности.