HTTP аутентификация

RFC 7235 определяет средства HTTP аутентификации, которые может использовать сервер для запроса у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом 401 (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок WWW-Authenticate, содержащий хотя бы один метод авторизации. Клиент, который хочет аутентифицироваться, может сделать это, включив в следующий запрос заголовок Authorization с требуемыми данными. Обычно, клиент отображает пользователю запрос (prompt) пароля, и после получения ответа отправляет запрос (request) с пользовательскими данными в заголовке Authorization.

В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.

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

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

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

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

Браузеры используют кодировку utf-8 для имени пользователя и пароля. Firefox использовал ISO-8859-1, но она была заменена utf-8 с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как Firefox bug 1419658).

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

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

Здесь, <type> - это схема аутентификации ("Basic" (базовая) это наиболее распространённая, представленная ниже). realm используется для описания защищённой области или для индикации области защиты. Это может быть сообщение типа "Access to the staging site" или подобное, чтобы пользователь знал, к какой области он пытается получить доступ.

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

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

Общая структура HTTP аутентификации является основной для ряда схем аутентификации. Schemes can differ in security strength and in their availability in client or server software.

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

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

• Basic (смотреть RFC 7617, зашифрованные с помощью base64 учётные данные. Больше информации смотреть снизу.),
• Bearer (смотреть RFC 6750, bearer токены для доступа OAuth 2.0-защищённых ресурсов),
• Digest (смотреть RFC 7616, Firefox 93 и более поздние версии поддерживают шифрование SHA-256. Предыдущие версии поддерживают только хэширование MD5 (не рекомендуется). ),
• HOBA (смотреть RFC 7486, Секция 3, HTTP Origin-Bound Authentication, digital-signature-based),
• Mutual (смотреть draft-ietf-httpauth-mutual),
• AWS4-HMAC-SHA256 (смотреть AWS документацию).

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

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

"Базовая" схема HTTP-аутентификации определена в RFC 7617, которая передаёт учётные данные в виде пар пользователь ID/пароль (user ID/password), закодированных с использованием base64.

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

Чтобы защитить паролем каталог на сервере 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 в URL-адресах часть username:password@ дажевырезана из соображений безопасности. В браузере Firefox, проверяется, действительно ли сайт требует аутентификации и если нет, тогда Firefox предупредит пользователя запросом (prompt) "You are about to log in to the site "www.example.com" with the username "username", but the website does not require authentication. This may be an attempt to trick you.".

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