Каждый разработчик, интегрировавший сторонний API, попал в одну стену: в документах говорится & quot;authenticate с помощью Basic auth, & quot; вы вставляете свой ключ и секрет в запрос, а сервер отвечает плоско 401 Unauthorized и нет намека на то, почему. Девять раз из десяти учетные данные были закодированы немного неправильно, и в ошибке нет ничего, что могло бы сказать вам, что. Я построил и потреблял достаточно API через плагины WordPress и серверные части Laravel, чтобы потратить смущающее количество времени именно на это, поэтому я поставил a базовый генератор авто во время Toolz.dev это каждый раз правильно строит заголовок и декодирует один обратно, когда вам нужно проверить. Это руководство к нему и к схеме, лежащей в его основе.
TL;DR: HTTP Basic Authentication отправляет имя пользователя и пароль как
base64(username:password)вAuthorizationзаголовок. Инструмент базовый генератор авто превращает имя пользователя и пароль в точный заголовок, команду curl готовности к запуску, фрагмент выборки и форму URL-адреса userinfo, и он декодирует существующие токены обратно. Он кодирует UTF-8, поэтому учетные данные, не относящиеся к ASCII, сохраняются, предупреждает, когда имя пользователя содержит двоеточие, и полностью работает на стороне клиента.
Что такое базовая аутентификация HTTP?
HTTP Basic Authentication - это простейшая схема учетных данных, которую определяет Интернет. Это указано в РФК 7617, который находится поверх общей структуры аутентификации HTTP РФК 7235. Идея минимальна: чтобы доказать, кто вы, вы отправляете Authorization заголовок, значением которого является слово Basic, пробел, а затем кодировка base64 вашего имени пользователя и пароля, соединенная одним двоеточием.
Конкретно, если ваше имя пользователя admin и ваш пароль secret, клиент формирует строку admin:secretкодирует его как байты UTF-8, base64-кодирует эти байты, которые нужно получить YWRtaW46c2VjcmV0и отправляет:
Authorization: Basic YWRtaW46c2VjcmV0
Это вся схема. нет рукопожатия, нет nonce, нет хеширования. его простота именно поэтому он выжил: это тривиально реализовать на обоих концах, а для внутренних инструментов, частных реестров, веб-крючков, и бесчисленных API это все еще является по умолчанию. загвоздка, и это большой, заключается в том, что кодировка полностью обратима, что формирует все о том, как вы должны использовать его.
Кодировка base64 - это то же самое, что шифрование?
Нет, и это самое важное, что нужно понять в Basic auth. Base64, определенный в RFC 4648, является транспортной кодировкой. ее цель представляет двоичные или текстовые данные с использованием безопасного набора из 64 печатных символов, чтобы он выжил, будучи отправленным через системы, которые ожидают текст. это не шифр, он не использует никакой ключ, и обращая его на противоположный, занимает один шаг. Любой, кто может видеть YWRtaW46c2VjcmV0 может декодировать его обратно в admin:secret мгновенно, что и делает этот режим декодирования инструмента 's.
Следствием является то, что Базовая аутентификация обеспечивает нулевую конфиденциальность сама по себе. Учетные данные фактически отправляются в ясном виде, просто с тонкой маскировкой. Вот почему единственное необоротное правило Базового аутентификации заключается в том, что он должен когда-либо путешествовать только по HTTPS. TLS шифрует весь запрос, включая Authorization заголовок, поэтому учетные данные base64 защищены при передаче Отправить базовую аутентификацию по простому HTTP, и вы опубликовали свой пароль для любого, кто находится на пути к сети.
Я работаю над этим пунктом, потому что шаг base64 обманывает людей, заставляя их думать, что учетные данные зашифрованы каким-то значимым образом. Это не так. Относитесь к токену base64 с той же тщательностью, с которой вы относились бы к необработанному паролю, потому что они тривиально взаимопреобразуемы. The онлайн-инструменты конфиденциальности данных руководство описывает, почему этот инструмент выполняет кодирование в вашем браузере, а не на сервере, и в этом вся суть для живых учетных данных.
Как шаг за шагом создается заголовок Basic auth?
Конструкция состоит из четырех небольших шагов, и если вы поймете любой из них немного неправильно, это приведет к бесшумному отказу сертификата:
- Присоединяйтесь к двоеточию. Сформировать строку
username:password. Двоеточие является разделителем. - Кодировать как UTF-8. Превратите эту строку в байты с помощью UTF-8. Это важно для любого символа, отличного от ASCII.
- Base64-кодировать байты. Примените стандартную базу64 для создания токена.
- Префикс с
Basic, йо- Окончательное значение заголовкаBasicза ним следует жетон.
выше генератор делает все четыре и передает вам готовый заголовок. Он также создает формы, которые вы фактически вставляете в терминал или кодовую базу: команду свертывания с помощью -u флаг, команда завивки с явным выражением -H 'Authorization: Basic ...' заголовок, фрагмент выборки, отдельный токен и форма URL-адреса userinfo https://user:pass@host. Разные задачи требуют разных форм, и ручная перепечатка базы64 - это именно то место, где прокрадываются ошибки.
Почему имя пользователя имеет большее значение, чем пароль?
В схеме есть одна асимметрия, которая постоянно сбивает людей с толку, и она исходит прямо с первого шага. Учетные данные разделены на в первую очередь двоеточие. это означает, что имя пользователя не может содержать двоеточие, потому что сервер прочитал бы первое двоеточие в вашем имени пользователя в качестве границы и передал бы остальную его часть в поле пароля. пароль, напротив, может содержать столько двоеточий, сколько пожелает, поскольку все после первого двоеточия является паролем.
RFC 7617 прямо заявляет: идентификатор пользователя не должен содержать двоеточие. Это легко нарушить, не замечая, особенно когда имя пользователя само по себе является чем-то структурированным, например ключом API или идентификатором в форме электронной почты, который включает в себя двоеточие. Генератор наблюдает именно за этим и предупреждает вас, когда имя пользователя содержит двоеточие, потому что полученные учетные данные будут декодироваться с разделением в неправильном месте и создавать 401, который не дает вам ни малейшего представления о причине.
Вот правило в таблице, потому что стоит быть однозначным.
| поле | Может содержать двоеточие? | Причина |
|---|---|---|
| Имя пользователя | нет | Первый двоеточие является разделителем |
| пароль | да | Все после первого двоеточия - это пароль |
Я отладил именно этот сбой в дикой природе, где служба выдала API & quot;usernames& quot; который иногда содержал двоеточие, и интеграция работала для большинства клиентов и загадочным образом провалилась для некоторых. Предупреждение инструмента и # 39;s спасло бы в тот же день.
Почему кодировка UTF-8 имеет значение?
Для имени пользователя и пароля, состоящих исключительно из ASCII, шаг кодирования невидим; каждый символ - это один байт, и base64 делает свое дело. в тот момент, когда учетная запись содержит букву с акцентом, нелатинский сценарий или эмодзи, кодировка байта становится решающей. RFC 7617 рекомендует UTF-8 именно для того, чтобы клиент и сервер согласовали байты для этих символов.
Наивный кодер, который предполагает, что один символ - это один байт, или который опирается на API браузера с устаревшим поведением, будет поврежден café или пароль в неправильные байты, и токен base64, который он производит, не будет соответствовать тому, что совместимый сервер вычислил из того же учетного данных, Результат - еще один молчащий 401. этот генератор кодирует учетные данные по UTF-8 вручную, поэтому пароль нравится café:naïve производит именно те байты, которые клиент RFC 7617 отправил бы, и сторона декодирования верно меняет его. если у вас когда-либо был учетные данные, которые работали для одного товарища по команде, а не для другого, символ, не относящийся к ASCII, закодированный непоследовательно, является главным подозреваемым.
Как декодировать базовый токен аутентификации?
Поскольку кодировка обратима, проверить учетные данные так же просто, как создать один. Возьмите часть после Basic , base64-декодировать его, читать результат как UTF-8, и разделить на первом двоеточии.The генератор'с режим декодирования делает следующее: вставить полный Authorization: Basic ... линия, голая Basic ... значение или просто токен, и он показывает вам имя пользователя и пароль, которые он несет.
Это действительно полезно, а не просто любопытство. когда вам вручают рабочий учет и просят воспроизвести его в новой среде, декодирование сообщает вам, какое именно имя пользователя и пароль оно кодирует, чтобы вы могли правильно их установить. Когда интеграция не удалась, расшифровка токена, который вы на самом деле отправляете, и сравнение его с тем, что вы намеревались, часто является самым быстрым способом обнаружить блуждающее пространство, неправильное поле или двоеточие в неправильном месте. И это яркое напоминание о точке конфиденциальности выше: если вы можете расшифровать его так легко, так может любой, кто перехватывает его через простой HTTP.
Где генератор подходит к другим инструментам
Базовый auth - один из нескольких инструментов учетных данных и запросов на сайте, которые используют одну и ту же модель без загрузки на стороне клиента. Когда проверяемый вами токен является токеном на предъявителя, а не базовым auth, Декодер JWT считывает утверждения из веб-токена JSON. Когда вам нужен хеш, а не кодировка, для контрольной суммы или дайджеста пароля хэш-генератор вычисляет это. Когда вы просто хотите кодировать или декодировать произвольную базу 64, а не конкретно учетные данные, конвертер base64 обрабатывает общий случай. и когда вы отлаживаете сам запрос и хотите знать, какой клиент его отправил, анализатор пользовательских агентов читает заголовок User-Agent.
Для более широкой карты того, как эти утилиты запросов и ответов работают вместе, Набор инструментов для веб-разработчиков обзор проходит через реалистичный сеанс отладки и Инструменты повышения производительности разработчик руководство охватывает сборку личного набора из них Базовый auth редко приходит изолированно, это обычно одна строка в запросе вы пытаетесь сделать работу.
Рабочий пример: подключение интеграции API
Позвольте мне заземлить это в задаче, которую я бью больше всего Вы интегрируете сторонний сервис, в документах которого говорится, что необходимо пройти аутентификацию с помощью Basic auth, используя ключ API в качестве имени пользователя и пустого пароля, или пару ключа и секрета Документы дают вам учетные данные, но не заголовок, и первый запрос не удался.
Надежный путь заключается в том, чтобы построить заголовок явно и проверить его с помощью curl, прежде чем писать строку кода приложения Вставить ключ и секрет в генераторскопируйте curl -H формируйте и запускайте его против известной конечной точки. если скручивание успешно, а ваш код нет, проблема в вашем коде 's запрашивает конструкцию, а не учетные данные, и вы только что сократили пространство поиска пополам. если скручивание также не удается, учетные данные сами по себе неверны, и декодирование токена подтверждает, какое именно поле выключено.
В плагине WordPress мне часто нужно вызвать внешний API из PHP, и правильное значение заголовка - это то, во что я вхожу wp_remote_get через Authorization аргумент заголовка. В Ларавеле это входит в withHeaders позвоните на HTTP-клиент, или я использую фреймворк's withBasicAuth помощник, который строит тот же заголовок для меня. в любом случае, имея известное-хорошее значение заголовка от генератора означает, что я отлаживаю свой код запроса против учетных данных, которые я уже доказал работает, а не отлаживаю оба сразу. В случае пустого пароля генератор зарабатывает себе на жизнь, потому что легко забыть, что key: с задней двоеточием это другой и часто правильный учет key один.
Последняя дисциплина является защитной. не вставлять результирующий заголовок в общий документ, билет или чат, и не отправлять Базовый аута по чему-либо, кроме HTTPS. токен является паролем. потому что этот инструмент кодирует в вашем браузере и никогда ничего не загружает, генерировать учетные данные безопасно; куда он идет после, на вас.
Когда мне следует использовать Basic auth, а когда нет?
Базовый auth не является подходящим инструментом для каждой работы, и знание того, где он подходит, убережет вас от неприятностей. Его сила в простоте: для вызовов от сервера к серверу, внутренних инструментов, частных реестров пакетов, заданий CI и веб-крючков, где два конца уже доверяют друг другу и все проходит через HTTPS, это трудно превзойти. не о чем договариваться, нет токена для обновления, и каждый HTTP-клиент и библиотека поддерживают его из коробки. Когда вы контролируете обе стороны и соединение зашифровано, базовый auth является совершенно разумным выбором, который продолжает работать в течение тридцати лет.
Его слабые стороны проявляются в тот момент, когда вы выходите за пределы этого поля. Поскольку учетные данные отправляются по каждому запросу, одна просочившаяся строка журнала или прокси-сервер, записывающий заголовки, постоянно раскрывает их, и вращение означает изменение их повсюду одновременно. У него нет понятия объема, поэтому базовый учетный данные - это "все или ничего": он не может предоставить доступ только для чтения или истечь через час. И он помещает реальный, долгоживущий пароль на провод при каждом вызове, тогда как схемы на основе токенов позволяют вам вместо этого раздать недолговечный, узкомасштабированный учетный данные.
Для аутентификации, ориентированной на пользователя, или в любом месте, где вам нужны области, срок действия или отзыв, токен на предъявителя является лучшей моделью Декодер JWT является сопутствующим инструментом для проверки тех. полезное эмпирическое правило: охват для Базовый автомат для машинного вызова вы полностью контролируете, и охват для токенов, когда третья сторона, браузер сеанс, или граница разрешения задействованы.Таблица ниже суммирует торговлю.
| Используйте базовую автографию для | Предпочитайте токены для |
|---|---|
| API между серверами вызывает ваш контроль | Пользовательские сеансы |
| Внутренние инструменты и частные реестры | Доступ с областью охвата или только для чтения |
| Задания CI и веб-перехваты через HTTPS | Полномочия, срок действия которых должен истечь |
Часто задаваемые вопросы
Что такое базовая аутентификация HTTP? HTTP Basic Authentication - это схема, при которой клиент отправляет имя пользователя и пароль с каждым запросом в заголовке авторизации. Значением является слово Basic, за которым следует кодировка base64 имени пользователя: password. Оно определено в RFC 7617 и является самым простым способом проверки учетных данных сервером.
Как построен заголовок Basic auth? Присоединяйтесь к имени пользователя и паролю с одним двоеточием, чтобы сформировать имя пользователя:password, закодируйте эту строку как UTF-8 байтов, base64-кодируйте байты и добавьте к результату префикс Basic. Последний заголовок - Authorization: Basic, за которым следует этот токен.
Безопасна ли базовая аутентификация? Только по HTTPS. Base64 - это кодирование, а не шифрование, поэтому любой, кто может прочитать заголовок, может мгновенно декодировать пароль. Базовый аута не обеспечивает конфиденциальности сам по себе и всегда должен быть отправлен через соединение TLS, чтобы быть безопасным.
Может ли имя пользователя содержать двоеточие? Нет. первый двоеточие отделяет имя пользователя от пароля, поэтому двоеточие в имени пользователя будет неправильно прочитано как граница и разделит учетные данные в неправильном месте. пароль может содержать любое количество двоеточий. генератор предупреждает вас, если у имени пользователя есть один.
Как декодировать базовый токен аутентификации? Возьмите часть base64 после Basic, base64-decode его, и прочитайте как текст UTF-8.В результате имя пользователя:password, разделенный на первом двоеточии.Вставьте любой основной заголовок auth в инструмент's декодируйте режим, чтобы сделать это мгновенно.
Что эквивалентно завитушке? имя пользователя Curl-U:password https://example.com делает то же самое, потому что curl строит для вас заголовок Авторизация: Базовый из значения -u. инструмент показывает и эту форму, и явную форму заголовка -H, чтобы вы могли скопировать то, что подходит.
Отправляет ли этот инструмент мои учетные данные куда-нибудь? Нет. кодирование и декодирование полностью выполняются в вашем браузере с помощью JavaScript. Ваше имя пользователя и пароль никогда не загружаются ни на один сервер, поэтому его безопасно использовать с реальными, живыми учетными данными.
Зачем использовать кодировку UTF-8 для учетных данных? RFC 7617 рекомендует UTF-8, чтобы имена пользователей и пароли, не относящиеся к ASCII, последовательно кодировались между клиентом и сервером. Кодер, который предполагает, что ASCII повредит буквы с акцентом или нелатинские сценарии, создавая токен, с которым сервер не может сравниться.
