Аутентификация в curl: Basic Auth, Bearer, cookie и прокси

В примерах используются условные домены api.example.com и proxy.example. Замените их адресами своего API и прокси. Выполняйте запросы только к ресурсам, доступ к которым вам разрешён; логин и токен должны соответствовать требованиям конкретного сервиса.

Какой способ авторизации выбрать

Что выдал сервис	Что использовать в curl
Логин и пароль HTTP Basic	--user
Access token для Bearer	--header "Authorization: Bearer ..." или --oauth2-bearer
Сессионный cookie	--cookie, при необходимости --cookie-jar для обновлений
API-ключ	Заголовок или другой способ, который указан в документации API
Отдельный логин прокси	--proxy-user, независимо от авторизации на сайте

Один способ не заменяет другой автоматически. Например, сессионный cookie сайта нельзя произвольно использовать как Bearer-токен API.

Basic Auth: логин и пароль

Чтобы curl запросил пароль интерактивно, передайте только имя пользователя:

curl --user demo_user "https://api.example.com/private"

Пароль не потребуется вписывать в саму команду. Basic Auth передаёт пару логина и пароля в кодировке Base64. Это обратимое кодирование, которое одинаково применяется с HTTP и HTTPS. Для защиты передачи используйте HTTPS и действительную проверку сертификата.

Форма --user "demo_user:demo_password" допустима как учебный синтаксис. Реальный пароль в командной строке может попасть в историю оболочки и список процессов. Для автоматизации используйте поддерживаемое вашей средой хранилище секретов или ограниченный по доступу конфигурационный файл.

Bearer-токен

Токен передают способом, который ожидает сервер. Пример для bash/zsh, где TOKEN заранее задан через безопасный механизм среды:

curl --header "Authorization: Bearer $TOKEN" "https://api.example.com/private"

Для сервиса с Bearer-аутентификацией также подходит:

curl --oauth2-bearer "$TOKEN" "https://api.example.com/private"

Наличие токена не означает бессрочный доступ. Проверьте срок действия, область разрешений и назначение токена. Любой, кто получил действующий Bearer-токен, может использовать его в пределах этих прав. Не выводите значение в журнал сборки.

Cookie: сохранение и повторное использование сессии

Опция --cookie-jar сохраняет cookie из ответа, а --cookie загружает их при следующем запросе. Чтобы использовать файл и сохранить обновления за один запуск:

curl --cookie cookies.txt --cookie-jar cookies.txt "https://api.example.com/private"

Этот пример предполагает, что файл уже содержит действительную сессию. Универсальной команды входа для всех сайтов нет: форма может требовать CSRF-токен, дополнительные поля, второй фактор или выполнение JavaScript. Сам факт выдачи cookie не подтверждает вход. Проверьте код ответа и доступ к защищённой странице.

Сессионный файл даёт доступ к аккаунту, поэтому ограничьте права на него и удалите после завершения работы, если хранение больше не требуется.

API-ключ и дополнительные заголовки

Название заголовка и его значение определяет API. Возможны Authorization: Bearer, отдельный заголовок ключа и другие схемы. Не придумывайте префикс ApiKey, если его нет в документации сервиса.

Для дополнительного заголовка используйте отдельный --header. Например, заголовок формата ответа:

curl --header "Authorization: Bearer $TOKEN" --header "Accept: application/json" "https://api.example.com/private"

Accept не выполняет авторизацию. Если API требует несколько заголовков, проверьте назначение каждого. Подробнее о синтаксисе читайте в руководстве по заголовкам curl.

OAuth и получение токена

curl отправляет HTTP-запрос к token endpoint по правилам конкретного сервиса. Endpoint, тип grant, клиентская авторизация, параметры и scope должны быть взяты из его документации.

Ответ OAuth с access token не обязан содержать JWT. Токен может быть непрозрачной строкой; используйте его как выданное значение. Подходящий grant также зависит от задачи: client_credentials относится к доступу приложения и не заменяет пользовательский вход.

Для обновления токена используйте поддерживаемую сервисом процедуру. Передача refresh token требует такой же защиты, как передача пароля.

Безопасная отладка

Передавайте секреты по HTTPS, сохраняйте проверку TLS-сертификатов и ограничивайте права токенов нужными действиями. В автоматизации избегайте публикации реальных значений в командах, конфигурации проекта и отчётах.

Режимы --verbose и --trace могут раскрывать чувствительные заголовки, cookie и параметры запросов. Автоматическое сокрытие всех секретов не гарантируется. Для первоначальной диагностики можно вывести код HTTP без подробной трассировки:

curl --silent --show-error --output response.txt --write-out "HTTP %{http_code}\n" --user demo_user "https://api.example.com/private"

Файл response.txt также может содержать закрытые сведения. Перед передачей отчёта удалите значения авторизации, сессионные cookie и персональные данные. В приведённых командах не требуется отключать проверку сертификата через --insecure.

Ошибки 401, 403 и 407

Ответ	Что проверить
401 Unauthorized	Правильность схемы авторизации, логина или токена, срок его действия
403 Forbidden	Права на ресурс, ограничения аккаунта и политику сервиса; причина не обязательно в IP
407 Proxy Authentication Required	Авторизацию на прокси, которая задаётся отдельно от сайта
Ошибка соединения до HTTP-ответа	DNS, адрес и порт, доступность сети и TLS

Для 401 полезно сверить ожидаемую схему в WWW-Authenticate, если сервер прислал этот заголовок. Для 407 проверьте данные прокси. Пример HTTP-прокси, где curl отдельно запросит пароль для прокси и для API:

curl --proxy "http://proxy.example:8080" --proxy-user demo_proxy_user --user demo_api_user "https://api.example.com/private"

В этом примере --proxy-user относится к прокси, а --user к целевому серверу. Передавайте каждому узлу только его собственные учётные данные.

Аутентификация при сборе данных через прокси

Успешная авторизация даёт только разрешённый аккаунту доступ. curl не выполняет JavaScript страницы как полноценный браузер. Проверяйте условия сервиса и используйте официальный API, когда он предусмотрен для вашей задачи.

Если запрос должен выходить через отдельный адрес, настройте прокси в curl. Для такого подключения можно выбрать прокси ProxyWing с подходящим протоколом и авторизацией. Смена адреса не восстанавливает истёкший токен и не добавляет права API.

Команды в PowerShell и CMD

В Windows PowerShell 5.1 имя curl может быть псевдонимом другой команды. Чтобы вызвать установленный curl, используйте curl.exe и проверьте версию через curl.exe --version.

Переменная токена в PowerShell:

curl.exe --header "Authorization: Bearer $env:TOKEN" "https://api.example.com/private"

В CMD переменная выглядит иначе:

curl.exe --header "Authorization: Bearer %TOKEN%" "https://api.example.com/private"

В bash/zsh применяется $TOKEN. Правила кавычек и переноса команд зависят от оболочки. Используйте обычные прямые кавычки и переносите приведённые однострочные примеры целиком.

Короткая проверка перед запросом

Убедитесь, что выбран правильный endpoint, схема авторизации и действующий секрет с нужными правами. Сначала различите ответ сайта и ответ прокси, затем исправляйте соответствующие параметры. При отладке сохраняйте код HTTP и обезличенное описание ошибки.