HTTP Negotiate

HTTP Negotiate — это механизм аутентификации в протоколе HTTP, основанный на протоколе SPNEGO (Simple and Protected GSS-API Negotiation Mechanism), который позволяет клиенту и серверу согласовать и использовать один из нескольких поддерживаемых методов аутентификации, чаще всего Kerberos или NTLM. HTTP Negotiate является расширением схемы аутентификации «Negotiate» (или «Negotiate»), определённой в стандарте RFC 4559, и широко применяется в корпоративных средах Microsoft Windows для обеспечения единого входа (Single Sign-On, SSO).

История и стандартизация

Протокол HTTP Negotiate был разработан корпорацией Microsoft для интеграции веб-приложений с инфраструктурой аутентификации Windows. В 2006 году он был описан в RFC 4559 «HTTP Authentication: SPNEGO-based Negotiate» (авторы — К. Зиглер, П. Левин, Дж. Уилсон). Стандарт определил механизм, при котором клиент и сервер обмениваются сообщениями в формате SPNEGO, позволяя выбрать наиболее подходящий протокол аутентификации — Kerberos (если доступен) или NTLM (как резервный вариант). Впоследствии поддержка Negotiate была реализована в большинстве современных веб-браузеров и серверов, включая Internet Explorer, Mozilla Firefox, Google Chrome, а также в серверных продуктах, таких как Microsoft IIS и Apache HTTP Server (с модулем mod_auth_kerb).

Принцип работы

HTTP Negotiate использует стандартный механизм HTTP-аутентификации, определённый в RFC 7235. Процесс начинается с того, что сервер отвечает на запрос клиента кодом состояния 401 (Unauthorized) и заголовком WWW-Authenticate: Negotiate. Клиент, поддерживающий этот механизм, отправляет ответ с заголовком Authorization: Negotiate <base64-encoded token>, где токен содержит данные SPNEGO. Сервер дешифрует токен, проверяет подлинность клиента (через Kerberos или NTLM) и, в случае успеха, возвращает запрашиваемый ресурс с заголовком Authentication-Info. В случае неудачи сервер может повторно отправить 401 с новым запросом.

Этапы аутентификации

1. Запрос клиента: Клиент отправляет HTTP-запрос к защищённому ресурсу без заголовка авторизации.
2. Ответ сервера: Сервер отвечает кодом 401 и заголовком WWW-Authenticate: Negotiate.
3. Формирование токена: Клиент (обычно через библиотеку GSS-API) генерирует токен SPNEGO, который содержит запрос к службе аутентификации (например, Kerberos). Токен кодируется в Base64 и включается в заголовок Authorization.
4. Проверка сервером: Сервер декодирует токен, извлекает учётные данные клиента и проверяет их через контроллер домена (для Kerberos) или через локальную базу (для NTLM). При успехе сервер возвращает ресурс и, опционально, устанавливает сессионный cookie.
5. Повторная аутентификация: Если сервер требует дополнительных шагов (например, для NTLM), он может отправить новый 401 с WWW-Authenticate: Negotiate и дополнительным токеном, после чего клиент повторяет шаг 3.

Поддерживаемые протоколы

HTTP Negotiate не является самостоятельным протоколом аутентификации, а выступает надстройкой, позволяющей согласовать использование одного из следующих механизмов:

• Kerberos: Предпочтительный метод, используемый в средах Active Directory. Обеспечивает взаимную аутентификацию клиента и сервера без передачи пароля по сети. Требует, чтобы клиент и сервер были в одном домене или доверенном лесу, а также чтобы сервер имел зарегистрированное имя службы (SPN) в DNS.
• NTLM: Резервный метод, применяемый, когда Kerberos недоступен (например, при работе через прокси-сервер или при отсутствии доверия между доменами). NTLM передаёт хэш пароля (или challenge/response) и менее безопасен, чем Kerberos, так как уязвим для атак типа «человек посередине» и перебора хэшей.

Применение

HTTP Negotiate используется в корпоративных веб-приложениях, где требуется бесшовная аутентификация пользователей без повторного ввода логина и пароля. Основные области применения:

• Веб-порталы и интранет-сайты: Например, Microsoft SharePoint, Exchange Web Access (OWA), Dynamics CRM.
• API-сервисы: RESTful API, защищённые через Kerberos, особенно в средах Windows Server и Azure.
• Прокси-серверы: Некоторые прокси-серверы (например, Microsoft Forefront TMG) используют Negotiate для аутентификации клиентов.
• Виртуальные частные сети (VPN): Некоторые VPN-шлюзы поддерживают Negotiate для входа через веб-интерфейс.

Поддержка в браузерах и серверах

Браузеры

• Internet Explorer: Встроенная поддержка Negotiate, включена по умолчанию для сайтов зоны «Интранет».
• Mozilla Firefox: Поддерживается через настройку network.negotiate-auth.trusted-uris, где указываются доверенные домены.
• Google Chrome: Использует системные настройки Windows (через SSPI) или Linux (через GSS-API). Требует указания доверенных URL в параметрах командной строки или через политики.
• Safari: Поддерживается на macOS через GSS-API, но требует настройки Kerberos.

Серверы

• Microsoft IIS: Встроенная поддержка через модуль Windows Authentication. Настраивается через диспетчер IIS или конфигурационные файлы.
• Apache HTTP Server: Требует модуля mod_auth_kerb (для Kerberos) или mod_auth_ntlm_winbind (для NTLM). В современных версиях Apache (2.4+) также доступен модуль mod_auth_gssapi.
• Nginx: Поддерживается через модуль ngx_http_auth_kerb_module (сторонний) или через проксирование на сервер с Negotiate (например, Apache или IIS).
• Tomcat: Поддерживается через Valve (например, org.apache.catalina.authenticator.SpnegoAuthenticator).

Безопасность и ограничения

HTTP Negotiate, особенно при использовании NTLM, имеет ряд уязвимостей. NTLM уязвим для атак типа «передача хэша» (pass-the-hash), когда злоумышленник, перехватив хэш пароля, может выдать себя за пользователя. Kerberos более безопасен, но требует правильной настройки SPN, синхронизации времени (с точностью до 5 минут) и защиты от атак «золотой билет» (Golden Ticket) при компрометации контроллера домена. Кроме того, Negotiate не поддерживает многофакторную аутентификацию (MFA) в базовом виде, что ограничивает его применение в современных сценариях безопасности.

Альтернативы

С развитием веб-стандартов и увеличением требований к безопасности, HTTP Negotiate постепенно вытесняется более современными протоколами:

• OAuth 2.0 и OpenID Connect: Обеспечивают делегированную аутентификацию и авторизацию, поддерживают MFA и не зависят от доменной инфраструктуры.
• SAML: Используется для федеративной аутентификации в корпоративных средах.
• WebAuthn (FIDO2): Позволяет использовать биометрию или аппаратные ключи для аутентификации без паролей.

Тем не менее, HTTP Negotiate остаётся широко распространённым в унаследованных корпоративных системах, особенно в организациях, использующих Microsoft Active Directory.

Источники

• RFC 4559 — HTTP Authentication: SPNEGO-based Negotiate (2006)
• RFC 7235 — Hypertext Transfer Protocol (HTTP/1.1): Authentication (2014)
• RFC 4178 — The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) (2005)
• Microsoft Docs: «Windows Authentication (IIS)»
• Apache HTTP Server Documentation: «mod_auth_kerb»
• Nginx Documentation: «ngx_http_auth_kerb_module»