Контрольная по информатике на тему: "Определение и применение OAuth"

Определение и применение OAuth.
1.1. Определение OAuth.
OAuth — открытый протокол (схема) авторизации, обеспечивающий
предоставление третьей стороне ограниченный доступ к защищённым
ресурсам пользователя без передачи ей (третьей стороне) логина и пароля.
OAuth возник в ноябре 2006 года, когда Блейн Кук разрабатывал
реализацию протокола OpenID для сервиса микроблогов Twitter. Совместно с
Крисом Мессиной он искал путь использовать OpenID для доступа к Twitter
API без предоставления сервису пароля. В сотрудничестве с одним из
создателей OpenID Девидом Рекордоном они провели анализ
функциональности OpenID, а также проприетарных протоколов авторизации,
таких как Flickr Auth, Google AuthSub и Yahoo! BBAuth, после чего пришли к
заключению, что существует необходимость в новом открытом протоколе.
В апреле 2007 года образовалась группа инженеров, работавших над его
созданием. В её работе приняли участие сотрудники компаний Google и
AOL. Финальная версия ядра протокола OAuth 1.0 была представлена 4
декабря 2007 года.
В 2010 году началась работа над совершенно новой версией протокола
OAuth 2.0, которая не будет обратно совместимой с OAuth 1.0. В октябре
2012 года структура OAuth 2.0 было опубликована в RFC.
В него планировалось добавить:
 6 новых потоков:
1) Поток пользователя – агента (User-Agent Flow) — для клиентов,
работающих внутри агента пользователя (обычно веб-браузер).
2) Поток веб – сервера (Web Server Flow) — для клиентов, которые
являются частью веб-приложения сервера, доступные через запросы HTTP.
3) Поток устройства (Device Flow) — подходит для клиентов,
выполняющихся на ограниченных устройствах, но там, где конечный
пользователь имеет отдельный доступ к браузеру на другом компьютере или
устройстве.
4) Поток имени пользователя и пароля(Username and Password Flow)
— используется в тех случаях, когда пользователь доверяет клиенту
обрабатывать свои полномочия, но он по-прежнему нежелательно разрешит
клиенту сохранить имя и пароль пользователя. Этот поток подходит только
когда есть высокая степень доверия между пользователем и клиентом.
5) Поток клиентских полномочий (Client Credentials Flow) — клиент
использует свои полномочия для получения токена.
6) Поток утверждения (Assertion Flow) — клиент представляет
утверждение, такие как утверждение SAML к серверу авторизации в обмен
на токен.
 Токен на предъявителя.
Метод авторизации аналогичен существующему способу авторизации с
помощью cookie. В этом случае токен непосредственно используется как
секрет (сам факт наличия токена авторизует клиента) и передается через
HTTPS. Это позволяет получать доступ к API посредством простых скриптов
(например, с использованием cURL).
 Упрощенная подпись.
Подпись была значительно упрощена, чтобы устранить необходимость в
специальном анализе, кодированиях и сортировках параметров.
 Короткоживущие токены с долговременной авторизацией.
Вместо выдачи долгоживущего токена (который за длительное время
может быть скомпрометирован), сервер предоставляет кратковременный
доступ и долговременную возможность обновлять токен без участия
пользователя.
 Разделение ролей.
За авторизацию и за предоставление доступа к API могут отвечать
разные сервера.