Генератор заголовка Basic Auth

Как сгенерировать заголовок Basic Auth

1. Введите Имя пользователя и Пароль.
2. Оставьте в поле Кодировка UTF-8, если только сервер не старый и не ждёт ISO-8859-1 (Latin-1).
3. Скопируйте результат: Скопировать заголовок берёт полную строку Authorization: Basic …, а Скопировать только токен – лишь часть в Base64.
4. В блоке Готовый код укажите в поле URL свой эндпоинт и скопируйте фрагмент для своего клиента. ⇄ Поменять местами отправляет заголовок в декодер для перепроверки.

Что содержит заголовок

Basic-аутентификация описана в RFC 7617. Клиент соединяет два значения двоеточием, кодирует байты в Base64 и отправляет их в одном заголовке:

Последние две строки показывают, почему важна кодировка: один и тот же текст даёт разные байты, и сервер, который ждёт другую кодировку, видит неверный пароль. Сервер, которому нужен UTF-8, может сообщить об этом в запросе на аутентификацию: WWW-Authenticate: Basic realm="api", charset="UTF-8".

Base64 здесь нужен только для передачи. Любой, кто скопирует заголовок, превратит его обратно в пароль декодером Basic Auth, поэтому Basic auth уместна только поверх HTTPS. Подробнее в статье Base64 – это не шифрование.

О каких символах предупреждает инструмент

• Двоеточие в имени пользователя. RFC 7617 это запрещает. Сервер делит строку по первому двоеточию, и часть имени окажется в пароле.
• Управляющие символы вроде табуляции или переносов строк, которые в учётных данных Basic недопустимы.
• Символы, которых нет в Latin-1, если выбрана эта кодировка, например эмодзи или кириллица. Они заменяются на ?, и пароль получается не тот.
• Не-ASCII в UTF-8. По RFC это правильно, но устаревшие серверы могут прочитать такие байты иначе, так что сначала проверьте.

Двоеточие в пароле допустимо: два значения разделяет только первое двоеточие.

Отправка Basic auth из кода

Инструмент подставляет во фрагменты ваши значения и экранирует их по правилам каждого языка. Базовые версии выглядят так:

curl -u 'deploy:hunter2' https://api.example.com/

import requests

r = requests.get("https://api.example.com/",
                 auth=("deploy".encode("utf-8"), "hunter2".encode("utf-8")))

Пример на Python намеренно передаёт байты. Получив значения str, requests кодирует их в Latin-1, и пароль с € или ł не пройдёт; с байтами отправляется ровно тот UTF-8, который вы выбрали.

В браузерном JavaScript собирайте заголовок сами: fetch отказывается работать с URL, в которых есть user:pass@, а btoa() падает на символах вне Latin-1, поэтому перед Base64 закодируйте строку в байты UTF-8. Сгенерированный фрагмент для fetch обходит обе проблемы: токен в нём уже готов. Шаг с UTF-8 объясняет руководство по Base64 в JavaScript, а версию с Buffer показывает страница Node.js.

Если запрос всё равно возвращает 401

Сначала посмотрите на заголовок WWW-Authenticate в ответе. Если там Bearer, API ждёт токен и учётные данные Basic не примет никогда. Если там Basic, декодируйте заголовок, который вы на самом деле отправили (curl -v печатает его как > Authorization: Basic …), и сравните с ожидаемым: часто виноваты лишние пробелы или перевод строки в конце, скопированный из менеджера паролей. Прокси используют собственный заголовок Proxy-Authorization того же формата.

Вопросы и ответы