HTTP. Часть 12. Безопасность и авторизация

Стандартный механизм заголовков HTTP также представляет ядро стандартного механизма безопасности HTTP.

Авторизация (authorization) — предоставление определённому лицу или группе лиц прав на выполнение определённых действий(процедур); а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.

Следовательно в контексте HTTP протокола — авторизация, это предоставления пользователю прав, на выполнение определенных действий на сайте, после подтверждения им его данных (ввода пароля, ….).

Безопасная транзакция документа происходит следующим образом:

  1. Клиент (браузер) запрашивает документ, используя стандартный метод GET.
    В этот момент клиент не знает о том, что документ защищен средствами безопасности.
  2. Доступ к документу запрещается с выдачей заголовка 401. Наряду с заголовком 401 сервер посылает требуемый метод авторизации, который должен быть использован клиентом в ответ (заголовок WWW-Authenticate).
  3. Браузер отвечает на заголовок 401, отображая диалоговое окно с запросом имени и пароля пользователя.
  4. Пользователь вводит имя и пароль и отправляет их. Браузер передает их серверу вместе с заголовком авторизации.
  5. Если доступ разрешен, запрошенный документ отправляется браузеру. Если же в доступе отказано, пользователь вновь получает диалоговое окно с запросом параметров авторизации и заполняет его.

Существует множество схем авторизации в HTTP. 

Основные из них это:

  • Базовая аутентификация(Basic)
  • Дайджест-аутентификация (Digest)
  • Аутентификация по предъявлению цифрового сертификата
  • Аутентификация по Cookies
  • Децентрализованная аутентификация (OpenID, OpenAuth, OAuth)

Обычно используется только одна из них — базовая (Basic) аутентификация.

По этой схеме заголовок авторизации имеет следующую форму:

Authorization: SCHEME REALM

Слово SCHEME может быть заменено на BASIC, а слово REALM — на закодированную форму данных авторизации (имени и пароля).
Это формат закодированного значения «имя:пароль» с использованием алгоритма base64. Предположим, что ваше имя — sJohnson, а пароль — duckduckgoose.

Применение кодирующего алгоритма base64 к ним даст нам такой заголовок авторизации:

Authorization: Basic c2pvaG5zb246ZHVja2RlY2tnb29zZQ==

Помимо Basic-аутентификации HTTP также применяется аутентификация Digest.

Несмотря на то что базовая аутентификация HTTP «закодирована», она в действительности не является безопасной, поскольку информация передается в открытом виде (кодирование маскирует, но реально не скрывает имя и пароль пользователя). Хотя аутентификация Digest технически более защищена, большинство Web-браузеров не поддерживают ее, а потому ее не поддерживают и большинство Web-сайтов.

Помимо традиционной защиты на базе HTTP, которая реализована на уровне Web-сервера, безопасность уровня приложений реализуется разработчиками приложений. Этот подход обычно использует cookie-наборы для сохранения идентификации пользователя. Ключевой выгодой отказа от применения HTTP-защиты является то, что это  дает возможность разработчику полностью контролировать вид и поведение формы регистрации пользователя.

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

Одним из главных минусов  децентрализованной аутентификации (OpenID, OpenAuth, OAuth) является то, что взлом дает доступ сразу ко многим сервисам.

НА ЗАМЕТКУ
Если вы хотите поэкспериментировать с кодировкой base64, обратитесь по адресу http://makcoder.sourceforge.net/demo/base64.php.

openid

  • Ольга

    Спасибо большое!

  • Андрей

    HTTP статус 301 — Moved Permanently. Скорей всего подразумевался статус 401.