Протокол авторизации OAuth 2.0

OAuth 2.0 (RFC 6749) является фреймворком для авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.

Стандарт OAuth 2.0 определяет следующие четыре роли:

  • владелец ресурса - сущность, обладающая правом на выдачу доступа к защищенным ресурсам. В случае, если владелец является человеком, его называют конечным пользователем;
  • сервер ресурсов - сервер, содержащий защищаемые ресурсы и обладающий возможностью получения и формирования ответа на запросы к защищаемым ресурсам посредством использования маркера доступа;
  • клиент - приложение, осуществляющее доступ к защищенным ресурсам от имени Владельца. Термин "клиент" явно не определяет какое-либо конкретное исполнение (будь то сервер, персональный компьютер или мобильное приложение);
  • сервер авторизации - сервер, осуществляющий выпуск маркеров доступа для клиентских приложений после успешной аутентификации и авторизации Владельца ресурсов.

Соответствие сущностей СЭП ролям OAuth 2.0 имеет следующий вид:

  • в качестве владельца ресурсов выступает Пользователь;
  • в качестве сервера ресурсов выступают компоненты СЭП, содержащие данные Пользователя (например, Сервис Подписи, Сервис Аудита, Хранилище Документов и т.п.)
  • клиентом является приложение, осуществляющее операции в СЭП. Приложением может являться браузер, толстый клиент или мобильное приложение.
  • ЦИ выступает в роли сервера авторизации.

Согласно OAuth, Клиентское Приложение запрашивает доступ к ресурсу, находящемуся в ведении Пользователя. Вместо использования учетных данных Пользователя, Приложение получает маркер доступа - строку, включающую в себя атрибуты доступа к ресурсу. Данные маркеры выпускаются Центром Идентификации с разрешения Пользователя (после его аутентификации).

Протокол OAuth обладает возможностью аутентификации не только Пользователя, но и клиентского приложения, осуществляющего доступ к ресурсам. Для этого протокол предусматривает такие параметры как client_id и client_secret.

сlient_id - это идентификатор клиентского приложения, используемый Центром Идентификации для поиска информации о клиенте.

client_secret является аналогом пароля для клиентского приложения и используется для аутентификации клиентского приложения на ЦИ. Компрометация секрета приводит к компрометации всех клиентских приложений, использовавших client_id, связанный с данными секретом.

Абстрактная схема взаимодействия описанных в протоколе ролей выглядит следующим образом:

image

  1. Клиентское приложение запрашивает авторизацию у Пользователя.
  2. Приложение получает разрешение на авторизацию (access grant), которое представляет из себя данные, описывающее авторизацию Приложения Пользователем. Разрешение на авторизацию может быть представлено одним из четырех типов, описанных в протоколе;
  3. Приложение запрашивает маркер доступа у Центра Идентификации, передавая ему разрешение на авторизацию, полученное от Пользователя;
  4. Центр Идентификации аутентифицирует клиента и проверяет валидность разрешения на авторизацию. В случае положительного исхода сервер формирует маркер доступа и передает его клиенту;
  5. Приложение запрашивает доступ к защищенному ресурсу (например, Сервису Подписи) и аутентифицируется на нем посредством маркера доступа, полученного ранее.
  6. Сервер с защищаемым ресурсом валидирует маркер доступа и в случае положительного исхода предоставляет доступ к запрашиваемым ресурсам.

Протокол определяет следующие типы разрешения на авторизацию:

  • код авторизации (authorization code);
  • неявный (implicit);
  • учетные данные владельца ресурса (resource owner);
  • учетные данные клиента (не используется СЭП).

Работа с ЦИ по протоколу OAuth 2.0 может быть описана одним из представленных ниже сценариев (подробнее). При этом, все сценарии можно разбить на два класса: требующие взаимодействия с пользователем через браузер и не требующие.

Под взаимодействием с пользователем понимается непосредственное взаимодействие Пользователя c Веб-Интерфейсом Центра Идентикации в рамках авторизации клиентского приложения, в то время как сценарии без взаимодействия с Пользователем могут выполняться по схеме Service-Service.

К сценариям, требующим обязательное взаимодействие с пользователям, относятся:

К сценариям которые могут выполняться без интерактивного взаимодействия с пользователям относят: