Digest-аутентификация. 
Разработка системы аутентификации "Контекстум-ID"

Недостатки:

для каждого запроса необходимо 2 запроса, что делает Digest-авторизацию более медленной: вызов любого нового метода предполагает получение нового значения nonce (случайно сгенерированное на сервере значение, предоставляется и используется единожды),.

уязвима к атаке man-in-the-middle, атака на воспроизведение, пароль, хранящийся на сервере, может быть взломан.

Схема действия (для случая перехода на страницу, требующей авторизации):

клиент запрашивает страницу, которая требует аутентифицироваться, но не предоставляет имя пользователя и пароль. Как правило, это происходит потому, что пользователь просто ввел адрес или проследовал по ссылке на страницу;

сервер отвечает 401 «клиент-ошибка», предоставляя область аутентификации и случайно сгенерированное, одноразовое значение;

на данном шаге клиент будет предоставлять область аутентификации (как правило, описание компьютера или системы, осуществляющей доступ) пользователю и запросит имя пользователя и пароль. Пользователь может принять решение об отмене в этот момент;

как только имя пользователя и пароль были предоставлены, клиент повторно посылает тот же самый запрос, но добавляет заголовок аутентификации, который включает код ответа;

в этом примере сервер принимает аутентификацию и страница возвращается. Если имя пользователя является недействительным и / или пароль неверный, сервер может вернуть код ответа «401» и клиент будет запрашивать их у пользователя еще раз [15].

Примечание: клиент может уже содержать имя пользователя и пароль, без необходимости запрашивать у пользователя, например, если они ранее были сохранены веб-браузером.

Использование SSL/TLS является обязательным.

Подготовка данных:

HA1 = MD5(«Mufasa: Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script :Circle Of Life»)= 939e7578ed9e3c518a452acee763bce9.

HA2 = MD5(«GET:/dir/index.html»)= 39aff3a2bab6126f332b942af96d3366.

Response = MD5(«939e7578ed9e3c518a452acee763bce9:dcd98b7102dd2f0e8b11d0f600bfb0c093:1:0a4f113b:auth:39aff3a2bab6126f332b942af96d3366»)= 6629fae49393a05397450978507c4ef1.

Таблица 1.2 — Пример запроса не аутентифицированного пользователя без указания учетных данных.

Таблица 1.3 — Ответ от сервиса для digest-аутентификации в случае неудачи авторизации.

Таблица 1.4 — Запрос клиента для digest-аутентификации (имя пользователя «User1», пароль «Password1»).

Таблица 1.5 — Ответ сервера для digest-аутентификации в случае удачной авторизации (имя пользователя «User1», пароль «Password1»).

OAuth (oAuth2).

Принцип работы oAuth заключается в использовании временных токенов.

Недостатки:

сложнее в реализации, является зависимым от состояния (аналогичен cookie — stateless),.

уязвим к атакам man-in-the-middle, воспроизведения.

Схема действия:

Оправдывает свое использование для клиентов 3ей стороны: у них нет логина, пароля и разрешений аналогичных пользовательским, поэтому необходимо отдельно хранить все разрешения для независимых клиентов. Для этих целей разработчик получает ключ API (API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password, — а пользователи разрешают доступ к части их разрешений. Например: доступ на просмотр имени, почтового адреса и прочего[16].

После выдачи разрешений третьей стороне, ей выдается токен на доступ, по которому они получают доступ уже к пользовательским разрешениям. Схема действия по протоколу OAuth 2.0 представлена на рисунке 1.2.

Рисунок 1.2 — Схема действия Bearer-аутентификации В большинстве случаев, сервер генерирует ключи доступа по запросу пользователей, которые далее сохраняют эти ключи в клиентских приложениях. При создании ключа также возможно ограничить срок действия и уровень доступа, который получит клиентское приложение при аутентификации с помощью этого ключа.