Каким способом и почему следует передавать токен в запросе?

Токен аутентификации — это секрет, который подтверждает, что запрос отправлен от имени конкретного пользователя. Главный вопрос не в том, как технически передать строку, а в том, где она может утечь. HTTP-запрос состоит из строки запроса (URL), заголовков и тела, и каждый из этих каналов по-разному логируется и кэшируется промежуточными системами.

Почему не в URL

Если передать токен как query-параметр, он попадёт в:

• логи веб-сервера, прокси и балансировщиков;
• историю браузера и закладки;
• заголовок Referer при переходах на внешние ресурсы;
• кэш CDN и промежуточных узлов.

Любой, кто получит доступ к этим данным, сможет выдать себя за пользователя.

Стандартный способ: заголовок Authorization

Спецификация RFC 6750 описывает схему Bearer: клиент отправляет токен в заголовке Authorization с префиксом Bearer. Заголовки не сохраняются в истории и обычно не пишутся в логи в открытом виде.

// Пример запроса с fetch
fetch('/api/profile', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer ' + accessToken,
    'Content-Type': 'application/json'
  }
});

// Пример с axios
axios.get('/api/profile', {
  headers: { Authorization: `Bearer ${accessToken}` }
});

Где хранить токен на клиенте

Для SPA токен обычно держат в памяти или в httpOnly-cookie. httpOnly-cookie защищает от XSS, но требует защиты от CSRF. Хранение в localStorage удобно, но уязвимо к XSS, поэтому важно экранировать пользовательский ввод.

Итог

Передавайте токен в заголовке Authorization со схемой Bearer — это стандарт, который не оставляет секрет в URL, логах и истории. Такой подход применяется в REST API, микросервисах и мобильных клиентах, где важна безопасность и совместимость с готовыми библиотеками.