Сформируйте заголовок HTTP Basic-аутентификации из имени пользователя и пароля, получите готовую команду curl для вставки и декодируйте существующий Basic-токен обратно в учётные данные.
Сформируйте заголовок HTTP Basic-аутентификации или декодируйте его. Введите имя пользователя и пароль, чтобы получить заголовок Authorization, сырой base64-токен и команду curl, которую можно вставить прямо в терминал. Декодер ниже выполняет обратное преобразование существующего токена.
Декодировать существующий токен
Всё вычисляется в вашем браузере, и ничего не передаётся. Тем не менее избегайте вставки рабочих учётных данных на любую веб-страницу, включая эту.
Как на самом деле работает HTTP Basic-аутентификация
Механизм
Basic-аутентификация, определённая в RFC 7617, — это самая простая схема в HTTP. Клиент соединяет имя пользователя и пароль двоеточием, кодирует результат в base64 и отправляет в заголовке:
Authorization: Basic YWxpY2U6czNjcjN0
Когда серверу нужны учётные данные, он отвечает 401 Unauthorized с заголовком WWW-Authenticate: Basic realm="...", и браузер показывает своё нативное окно входа. Нет рукопожатия, нет nonce и нет срока действия — каждый запрос несёт тот же заголовок.
Base64 — это не шифрование
Это то, что все должны усвоить. Base64 — это обратимое транспортное кодирование без ключа и без секрета. Любой, кто увидит заголовок, может декодировать его мгновенно — именно это делает декодер на этой странице. Поэтому Basic-аутентификация сама по себе обеспечивает нулевую конфиденциальность и должна использоваться только поверх HTTPS, где TLS защищает весь запрос. По обычному HTTP это равносильно отправке пароля в открытом виде.
Правило двоеточия
Имя пользователя не может содержать двоеточие, потому что первый двоеточие — это разделитель. Пароль может содержать сколько угодно двоеточий — декодер разбивает по первому и трактует остальное как пароль. Если имя пользователя действительно требует двоеточия, Basic-аутентификация неприменима, и нужна другая схема.
Кодировка символов
Первоначальная спецификация была расплывчатой насчёт всего, что вне ASCII, что исторически приводило к поломке не-ASCII паролей между клиентами и серверами. RFC 7617 добавил параметр charset="UTF-8", чтобы сервер мог заявить своё ожидание, и на практике каждый современный стек использует UTF-8. Этот инструмент кодирует в UTF-8 байты перед base64, соответствуя текущему поведению браузеров.
Где это всё ещё имеет смысл
Basic-аутентификация остаётся разумным выбором для машинных вызовов внутри локальных сетей, для быстрой защиты тестовой среды за nginx или Apache, для CI-задач, которым нужны простые учётные данные, и как транспорт для API-ключей, где ключ помещается в поле имени пользователя, а пароль остаётся пустым или устанавливается в значение-заполнитель, например x. Несколько платёжных и почтовых API используют именно этот шаблон.
Это плохой выбор для входа конечных пользователей на публичном сайте. Нет выхода, браузер кэширует учётные данные на сессию, диалог нельзя стилизовать, и нет способа добавить многофакторную аутентификацию или ограничение частоты на сессию. Используйте схему на основе токена или сессии.
Практические предостережения
Учётные данные, встроенные в URL — user:pass@example.com — считаются устаревшими и блокируются или удаляются большинством браузеров, потому что они утекают в историю, логи и заголовки referrer. Передача -u user:pass в curl также записывает пароль в историю оболочки и в список процессов, где его могут увидеть другие пользователи машины; предпочтительнее -u user и пусть curl запросит пароль, либо читайте значение из переменной окружения.
Часто задаваемые вопросы
Безопасна ли Basic-аутентификация?
Только поверх HTTPS. Кодирование base64 не даёт вообще никакой защиты — оно тривиально обратимо. С TLS учётные данные защищены при передаче как любые другие данные запроса; без TLS они фактически являются открытым текстом.
Зачем base64, если это не шифрование?
Его назначение — безопасность транспорта, а не секретность. Base64 гарантирует, что учётные данные содержат только безопасные для заголовка ASCII-символы, поэтому двоеточие, пробел или не-ASCII байт в пароле не могут испортить заголовок.
Может ли имя пользователя содержать двоеточие?
Нет. Первое двоеточие отделяет имя пользователя от пароля, поэтому двоеточие в имени делает учётные данные неоднозначными. Пароли могут содержать любое количество двоеточий.
Как выйти из Basic-аутентификации?
Правильного механизма нет. Браузеры кэшируют учётные данные на сессию, и обычные обходные пути — закрыть браузер или вернуть 401 на специальный эндпоинт. Это одна из причин, почему Basic-аутентификация неподходяща для входа конечных пользователей.
Истекает ли срок действия токена?
Никогда. Тот же заголовок действителен, пока не сменится пароль, поэтому утёкший Basic-токен так же серьёзен, как утёкший пароль. Меняйте учётные данные, если они когда-либо раскроются.
Куда-нибудь отправляются мои учётные данные?
Нет. Кодирование и декодирование выполняются полностью в вашем браузере. Тем не менее хорошей практикой является никогда не вставлять настоящие рабочие учётные данные на любую веб-страницу.