RFC 7235 определяет платформу аутентификации HTTP, которую сервер может использовать для запроса у клиента и клиент может использовать для предоставления информации об аутентификации.

Процесс запроса и ответа происходит следующим образом:

1. Сервер отвечает клиенту с кодом состояния 401 (Неавторизован) и предоставляет информацию о том, как авторизоваться с помощью заголовка ответа WWW-Authenticate, содержащего по меньшей мере один запрос.
2. Клиент, желающий пройти аутентификацию на сервере, может сделать это, включив заголовок запроса Authorization с учетными данными.
3. Обычно клиент выводит запрос пароля пользователю и затем отправляет запрос с правильным заголовком Authorization.

Общий порядок сообщений выше одинаков для большинства (если не всех) схем аутентификации. Фактическая информация в заголовках и способ её кодирования изменяются!

Тот же механизм запроса и ответа может быть использован для аутентификации прокси-сервера. Поскольку аутентификация ресурса и аутентификация прокси-сервера могут сосуществовать, требуется другой набор заголовков и кодов состояния. В случае прокси-серверов код состояния запроса — 407 (Требуется аутентификация прокси), заголовок ответа Proxy-Authenticate содержит по меньшей мере один запрос, применимый к прокси, и заголовок запроса Proxy-Authorization используется для предоставления учетных данных прокси-серверу.

Если сервер (прокси) получает неверные учетные данные, он должен ответить кодом состояния 401 Unauthorized или 407 Proxy Authentication Required, и пользователь может отправить новый запрос или заменить заголовок Authorization.

Если сервер (прокси) получает верные учетные данные, которые недостаточно для доступа к данному ресурсу, сервер должен ответить кодом состояния 403 Forbidden. В отличие от 401 Unauthorized или 407 Proxy Authentication Required, аутентификация для этого пользователя невозможна, и браузеры не предложат новую попытку.

Во всех случаях сервер может предпочесть вернуть код состояния 404 Not Found, чтобы скрыть существование страницы для пользователя без надлежащих привилегий или не прошедшего аутентификацию.

Возможная брешь в безопасности (которая впоследствии была исправлена в браузерах) заключалась в аутентификации изображений с других сайтов. Начиная с Firefox 59 и далее, ресурсы изображений, загруженные с других доменов, больше не могут вызывать диалоговые окна аутентификации HTTP (баг 1423146), предотвращая кражу учетных данных пользователя, если злоумышленники могли встраивать произвольное изображение на стороннюю страницу.

Браузеры используют кодировку utf-8 для имен пользователей и паролей.

Firefox когда-то использовал ISO-8859-1, но перешел на utf-8 для согласованности с другими браузерами и для предотвращения потенциальных проблем, как описано в баг 1419658.

Заголовки ответа WWW-Authenticate и Proxy-Authenticate определяют метод аутентификации, который должен быть использован для получения доступа к ресурсу. Они должны указать, какая схема аутентификации используется, чтобы клиент, желающий пройти авторизацию, знал, как предоставить учетные данные.

Синтаксис этих заголовков следующий:

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

Здесь <type> — схема аутентификации ("Basic" — самая распространенная схема и описана ниже). Realm используется для описания защищенной области или для указания области защиты. Это может быть сообщение, например, "Доступ к тестовому сайту" или подобное, чтобы пользователь знал, к какой области он пытается получить доступ.

Заголовки запроса Authorization и Proxy-Authorization содержат учетные данные для аутентификации агента пользователя на сервере (прокси). Здесь снова необходимо <type>, за которым следуют учетные данные, которые могут быть закодированы или зашифрованы в зависимости от используемой схемы аутентификации.

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

Общая платформа аутентификации HTTP служит основой для ряда схем аутентификации.

IANA поддерживает список схем аутентификации, но существуют и другие схемы, предлагаемые службами хостинга, такие как Amazon AWS.

Некоторые распространенные схемы аутентификации включают:

Basic

См. RFC 7617, учетные данные, закодированные с использованием base64. Дополнительная информация ниже.

Bearer

См. RFC 6750, токенизированные учетные данные для доступа к ресурсам, защищенным OAuth 2.0

Digest

См. RFC 7616. Firefox 93 и более поздние версии поддерживают алгоритм SHA-256. Более ранние версии поддерживают только хэширование MD5 (не рекомендуется).

HOBA

См. RFC 7486, Раздел 3, HTTP Origin-Bound Authentication, аутентификация на основе цифровой подписи

Mutual

См. RFC 8120

Negotiate / NTLM

См. RFC4599

VAPID

См. RFC 8292

SCRAM

См. RFC 7804

AWS4-HMAC-SHA256

См. AWS docs. Эта схема используется для аутентификации сервера AWS3.

Схемы могут отличаться по уровню безопасности и доступности в клиентском или серверном программном обеспечении.

Схема "Basic" обеспечивает очень слабую безопасность, но широко поддерживается и проста в настройке. Она рассматривается подробнее ниже.

Схема аутентификации "Basic" HTTP определена в RFC 7617, которая передает учетные данные как пары идентификатор пользователя/пароль, закодированные с использованием base64.

Поскольку идентификатор пользователя и пароль передаются по сети в виде открытого текста (они закодированы base64, но base64 — обратимое кодирование), схема аутентификации Basic не является безопасной. Для использования схемы аутентификации Basic необходимо использовать HTTPS/TLS. Без этих дополнительных функций безопасности схема аутентификации Basic не должна использоваться для защиты конфиденциальной или ценной информации.

Для защиты каталога на сервере Apache паролем вам потребуется файл .htaccess и файл .htpasswd.

Файл .htaccess обычно выглядит так:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

Файл .htaccess ссылается на файл .htpasswd, в котором каждая строка содержит имя пользователя и пароль, разделенные двоеточием (:). Вы не можете видеть фактические пароли, так как они захешированы (в данном случае используется хэширование на основе MD5). Обратите внимание, что вы можете назвать файл .htpasswd по-другому, но помните, что этот файл не должен быть доступен для всех. (Apache обычно настроен на предотвращение доступа к файлам .ht*).

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Для Nginx необходимо указать расположение защищаемого ресурса и директиву auth_basic, которая указывает имя защищенной области. Директива auth_basic_user_file затем указывает на файл .htpasswd, содержащий зашифрованные учетные данные пользователя, как и в примере для Apache.

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Многие клиенты также позволяют избежать запроса на вход, используя закодированный URL, содержащий имя пользователя и пароль, как показано ниже:

https://username:password@www.example.com/

Использование таких URL устарело. В Chrome часть username:password@ в URL даже удаляется по соображениям безопасности. В Firefox проверяется, действительно ли сайт требует аутентификации. Если нет, Firefox предупредит пользователя сообщением "Вы собираетесь войти на сайт "www.example.com" с именем пользователя "username", но сайт не требует аутентификации. Это может быть попытка обмана."

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407