Authorization

Применение

Запросный заголовок Authorization служит для получения доступа к защищённому ресурсу и обычно отправляется после того, как клиент узнал об ограничении доступа. Например, получив от сервера HTTP-ответ 401 Unauthorized с заголовком WWW-Authenticate, клиент передаёт учётные данные именно таким образом.

Примечание

Браузеры удаляют заголовок Authorization, когда запрос перенаправляется на другой источник. Это предотвращает утечку учётных данных, если перенаправление ведёт на сторонний сервер. Поведение определено в WHATWG Fetch Standard и поддерживается во всех современных браузерах. Приложениям, полагающимся на заголовки Authorization при межисточниковых перенаправлениях, необходимо выполнять повторную аутентификацию в конечной точке назначения. Инструменты вроде curl, Python Requests и HTTP-клиента Go следуют той же конвенции.

authentication-scheme

Директива authentication-scheme обязательна и сопровождается необязательными параметрами, специфичными для схемы. Схема определяет способ кодирования учётных данных. Распространённые варианты: Basic, Bearer, Digest и Negotiate.

Пример

В этом примере клиент использует схему аутентификации Basic. Обязательным параметром выступают учётные данные — пара username:password, закодированная в base64.

Authorization: Basic RXhhbXBsZTphaQ==

Токен Bearer распространён в API на основе OAuth 2.0. Токен представляет собой непрозрачную строку или подписанный JWT, выданный сервером авторизации.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Диагностика

Сбои авторизации обычно проявляются как неожиданные ответы 401 или как молча отброшенные учётные данные.

Учётные данные удаляются при межисточниковом перенаправлении. Браузеры и HTTP-клиенты удаляют заголовок Authorization, когда запрос перенаправляется на другой источник. Решение — отправлять учётные данные непосредственно в конечную точку назначения либо повторно аутентифицироваться после завершения перенаправления. Исследуйте цепочки перенаправлений с помощью curl -L -v, чтобы определить, где исчезает заголовок.

Ошибки кодирования base64 в аутентификации Basic. Закодированная строка должна содержать ровно одно двоеточие, разделяющее имя пользователя и пароль. Отсутствующее двоеточие или дважды закодированное значение дают искажённый токен, который сервер отклоняет. Проверьте исходное значение командой echo -n “user:pass” | base64 и сравните со значением заголовка, отправленным в запросе.

Токен Bearer истёк или некорректен. Токены содержат утверждение об истечении срока, и серверы отклоняют просроченные токены с кодом 401. Декодируйте JWT на jwt.io или командой echo "" | base64 -d, чтобы изучить поле exp. Логика обновления токена должна срабатывать до истечения его срока, а не после того, как сервер отклонит запрос.

Петля 401, когда сервер не отправляет WWW-Authenticate. Сервер возвращает 401, но не включает заголовок WWW-Authenticate, оставляя клиента без указания на ожидаемую схему. Проверьте заголовки ответа командой curl -I https://example.re/resource и убедитесь, что конфигурация сервера включает этот заголовок. В nginx директива auth_basic добавляет заголовок автоматически. Собственным бэкендам нужно задавать заголовок явно.

Предварительный запрос CORS блокирует заголовок Authorization. Межисточниковые запросы с Authorization вызывают предварительный запрос OPTIONS. Сервер обязан ответить на него заголовком Access-Control-Allow-Headers: Authorization. Отсутствующее или неверное значение заставляет браузер заблокировать запрос до отправки учётных данных. Во вкладке Network в DevTools предварительный запрос отображается отдельной записью OPTIONS.

curl отправляет учётные данные не в ту конечную точку. Запуск curl -H “Authorization: Bearer …” с флагом -L следует за перенаправлениями, но удаляет заголовок при переходах на другой источник. Используйте curl -v без -L, чтобы отправить заголовок точно в нужную конечную точку, либо передайте —location-trusted, чтобы принудительно пересылать учётные данные через перенаправления (применяйте с осторожностью и только на доверенных доменах).

Basic против Bearer

Basic и Bearer — две самые распространённые схемы аутентификации, решающие разные задачи.

Basic отправляет пару username:password, закодированную в Base64, в каждом запросе. Кодирование тривиально обратимо, поэтому HTTPS обязателен. Учётные данные статичны и привязаны к учётной записи пользователя, поэтому при компрометации пароля требуется сменить сам пароль. Basic хорошо подходит для внутренних инструментов и простых интеграций, где управление токенами добавляет излишнюю сложность.

Bearer использует непрозрачные токены (часто JWT), выданные сервером авторизации. Токены истекают, несут ограниченные области действия и могут быть отозваны без смены исходного пароля. Bearer — стандартный механизм для API и потоков OAuth 2.0. У украденного токена ограниченные срок жизни и область действия, что снижает масштаб ущерба по сравнению с утёкшим паролем.

Обе схемы передают учётные данные в открытом виде внутри значения заголовка. Ни одна из них сама по себе не обеспечивает шифрования. HTTPS необходим независимо от выбранной схемы.

Межисточниковый запрос к API с токеном Bearer через Fetch API.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})