Базовая аутентификация доступа
В контексте HTTP транзакции базовая аутентификация доступа — это метод, с помощью которого пользовательский агент HTTP (например, веб-браузер ) предоставляет имя пользователя и пароль при выполнении запроса. При базовой HTTP-аутентификации запрос содержит поле заголовка в форме Authorization: Basic <credentials>, где <credentials> — это кодировка Base64 идентификатора и пароля, соединенных одним двоеточием. :.
Первоначально он был реализован Ари Луотоненом в ЦЕРНе в 1993 году. [1] и определен в спецификации HTTP 1.0 в 1996 году. [2] Это указано в RFC 7617 от 2015 года, который устарел. RFC 2617 от 1999 года.
Функции
[ редактировать ]Реализация базовой аутентификации HTTP (BA) — это самый простой метод обеспечения контроля доступа к веб-ресурсам, поскольку он не требует файлов cookie , идентификаторов сеансов или страниц входа; скорее, базовая аутентификация HTTP использует стандартные поля в заголовке HTTP .
Безопасность
[ редактировать ]Механизм BA не обеспечивает защиту конфиденциальности передаваемых учетных данных. Они просто кодируются с помощью Base64 при передаче и не шифруются и не хэшируются никаким образом . Поэтому базовая аутентификация обычно используется в сочетании с HTTPS для обеспечения конфиденциальности.
Поскольку поле BA должно отправляться в заголовке каждого HTTP-запроса, веб-браузеру необходимо кэшировать учетные данные в течение разумного периода времени, чтобы избежать постоянного запроса у пользователя имени пользователя и пароля. Политика кэширования различается в разных браузерах.
HTTP не предоставляет веб-серверу метода, позволяющего клиенту «выйти из системы» пользователя. Однако существует ряд способов очистки кэшированных учетных данных в некоторых веб-браузерах. Один из них — перенаправление пользователя на URL-адрес в том же домене с использованием намеренно неверных учетных данных. Однако такое поведение несовместимо между различными браузерами и версиями браузеров. [3] Microsoft Internet Explorer предлагает специальный метод JavaScript для очистки кэшированных учетных данных: [4]
<script>document.execCommand('');</script>
В современных браузерах кэшированные учетные данные для базовой аутентификации обычно удаляются при очистке истории посещений. Большинство браузеров позволяют пользователям специально удалять только учетные данные, хотя эту опцию может быть трудно найти, и обычно они очищают учетные данные для всех посещенных сайтов. [5] [6]
Подбор учетных данных активно не предотвращается и не обнаруживается (если не используется механизм на стороне сервера).
Протокол
[ редактировать ]Серверная часть
[ редактировать ]Когда сервер хочет, чтобы пользовательский агент аутентифицировал себя на сервере после получения неаутентифицированного запроса, он должен отправить ответ со HTTP 401 Unauthorized. строкой статуса [7] и поле заголовка WWW-Authenticate . [8]
Поле заголовка WWW-Authenticate для базовой аутентификации строится следующим образом:
WWW-Authenticate: Basic realm="User Visible Realm"
Сервер может включить параметр charset из RFC 7617 : [3]
WWW-Authenticate: Basic realm="User Visible Realm", charset="UTF-8"
Этот параметр указывает, что сервер ожидает, что клиент будет использовать UTF-8 для кодирования имени пользователя и пароля (см. ниже).
Клиентская часть
[ редактировать ]Когда пользовательский агент хочет отправить учетные данные аутентификации на сервер, он может использовать поле заголовка авторизации .
Поле заголовка авторизации строится следующим образом: [9]
- Имя пользователя и пароль объединяются одним двоеточием (:). Это означает, что само имя пользователя не может содержать двоеточие.
- Результирующая строка кодируется в последовательность октетов. Набор символов, используемый для этой кодировки, по умолчанию не указан, если он совместим с US-ASCII, но сервер может предложить использовать UTF-8, отправив параметр charset . [9]
- Результирующая строка кодируется с использованием варианта Base64 (+/ и с дополнением).
- Затем к закодированной строке добавляются метод авторизации и пробел (например, «Basic»).
Например, если браузер использует Aladdin в качестве имени пользователя и open sesame в качестве пароля, то значением поля будет кодировка Base64 Aladdin:open sesame или QWxhZGRpbjpvcGVuIHNlc2FtZQ== . Тогда поле заголовка авторизации будет выглядеть так:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
См. также
[ редактировать ]- Дайджест-аутентификация доступа
- HTTP-заголовок
- TLS-SRP — альтернатива, если вы хотите избежать передачи эквивалента пароля на сервер (даже зашифрованного, как с помощью TLS).
Ссылки и примечания
[ редактировать ]- ^ Луотонен, Ари (10 сентября 2022 г.). «Объявление о документации по авторизации доступа» . [электронная почта защищена] (список рассылки) . Проверено 7 февраля 2022 г.
- ^ «Протокол передачи гипертекста — HTTP/1.0» . www.w3.org . W3C. 19 февраля 1996 года . Проверено 7 февраля 2022 г.
- ^ Jump up to: а б «Существует ли браузер, эквивалентный ClearAuthenticationCache в IE?» . StackOverflow . Проверено 15 марта 2013 г.
- ^ "
IDM_CLEARAUTHENTICATIONCACHEидентификатор команды» . Microsoft . Получено 15 марта 2013 г. - ^ «540516 — Удобство использования: разрешить пользователям очищать данные базовой аутентификации HTTP («Выход»)» . bugzilla.mozilla.org . Проверено 6 августа 2020 г.
Очистить недавнюю историю->Активные входы (в деталях) используется для очистки аутентификации.
- ^ «Очистить данные браузера – Компьютер – Справка Google Chrome» . support.google.com . Проверено 6 августа 2020 г.
Данные, которые можно удалить[...]Пароли: Записи сохраненных вами паролей удаляются.
- ^ «RFC 1945, раздел 11. Аутентификация доступа» . IETF. Май 1996 г. с. 46 . Проверено 3 февраля 2017 г.
- ^ Филдинг, Рой Т .; Бернерс-Ли, Тим ; Хенрик, Фристик. «Протокол передачи гипертекста — HTTP/1.0» . www.tools.ietf.org .
- ^ Jump up to: а б Решке, Джулиан. «Базовая» схема HTTP-аутентификации» . www.tools.ietf.org .
Внешние ссылки
[ редактировать ]- «RFC 7235 — Протокол передачи гипертекста (HTTP/1.1): Аутентификация» . Целевая группа инженеров Интернета (IETF). Июнь 2014. .