Сценарии авторизации
Данный раздел содержит в себе описание типовых сценариев взаимодействия клиентов с Центром Идентификации.
Раздел описывает следующие сценарии авторизации клиентского приложения на Центре Идентификации:
- Авторизация с использованием кода авторизации по протоколу OAuth 2.0
- Авторизация с аутентификацией по сертификату с использованием кода авторизации по протоколу OAuth 2.0
- Авторизация с использованием типа разрешения Implicit по протоколу OAuth 2.0
- Авторизация с использованием учетных данных владельца ресурса по протоколу OAuth 2.0
- Получение операторского делегирующего маркера доступа к ресурсу
Центр Идентификации предоставляет следующие конечные точки для аутентификации по OAuth:
- oauth/authorize - используется для инициирования процедуры авторизации;
- oauth/authorize/certificate - используется для инициирования авторизации с аутентификацией по сертификату;
- oauth/token - используется для получения маркера доступа.
Примечание
Для аутентификации по сертификату в URL-адресе запроса следует использовать HTTPS-порт, для которого на веб-сервере настроено требование TLS-соединения с двусторонней аутентификацией.
Соответствие между конечными точками и сценариями, их использующими, представлено ниже:
| Сценарий авторизации | Используемые конечные точки |
|---|---|
| Авторизация с использованием кода авторизации | oauth/authorize - запрос кода авторизации oauth/token - получение маркера доступа по коду авторизации |
| Авторизация с аутентификацией по сертификату | oauth/authorize/certificate - запрос кода авторизации oauth/token - получение маркера доступа по коду авторизации |
| Авторизация с использованием типа разрешения Implicit | oauth/token - получение маркера доступа (после аутентификации) |
| Авторизация с использованием учетных данных владельца ресурса | oauth/token - получение маркера доступа |
| Получение операторского делегирующего маркера доступа к ресурсу | oauth/authorize/certificate - запрос кода авторизации оператором oauth/token - получение маркера доступа оператора, получение делегирующего маркера |
Авторизация с использованием кода авторизации по протоколу OAuth 2.0
Работа протокола OAuth 2.0 в режиме с использованием типа разрешения Authorization Code строится вокруг так называемого кода авторизации, представляющего из себя промежуточное звено между Владельцем Ресурсов и Клиентским приложением.
Вместо прямого запроса на авторизацию у Владельца Ресурса, Клиентское приложение перенаправляет его на доверенный Центр авторизации.
Данный сценарий является самым защищенным и наиболее предпочтителен для использования клиентским приложением
Описание сценария может быть найдено здесь.
Авторизация с аутенификацией по сертификату с использованием кода авторизации по протоколу OAuth 2.0
Данный сценарий используется в случае, когда необходимо совместить возможность аутентификации по сертификату и преимущества протокола OAuth 2.0 в режиме работы с типом разрешения Код Авторизации.
Сценарий аналогичен предыдущему, но имеет следующее отличие. В процессе выполнения данного сценария устанавливается двустороннее TLS-соединение. Центр Идентификации в процессе обработки запроса пытается извлечь клиентский сертификат и, используя его, идентифицировать и аутентифицировать пользователя.
Таким образом, данный сценарий может использоваться тогда, когда отсутствует возможность интерактивного взаимодействия с пользователем.
Описание сценария может быть найдено здесь.
Авторизация с использованием типа разрешения Implicit по протоколу OAuth 2.0
Режим протокола OAuth 2.0 с неявным типом разрешения используется мобильными и веб-приложениями (приложениями, которые работают в веб-браузере), где конфиденциальность секрета клиента не может быть гарантирована. Так же, как и в случае с типом разрешения Код Авторизации, протокол использует механизм перенаправлений пользовательского агента, однако присутствуют ряд значительных отличий:
- неявный тип разрешения не поддерживает механизм маркеров обновления маркера доступа.
- отсутствует аутентификация клиентского приложения.
- адрес перенаправления не передается в запросе, а берется непосредственно из информации о клиенте, зарегистрированном ранее на ЦИ.
- операция получения маркера доступа выполняется в один шаг вместо двух.
Описание сценария может быть найдено здесь.
Авторизация с использованием учетных данных владельца ресурса по протоколу OAuth 2.0
Режим работы протокола OAuth 2.0 с типом разрешения: Учетные данные Владельца ресурса подходит для использования в тех случаях, когда Владелец данных доверяет Клиентскому приложению.
Данный тип можно использовать тогда, когда Клиентское приложение имеет возможность тем или иным образом получить учетные данные Владельца данных (логин и пароль), однако данный режим является наименее защищенным и должен применяться только в случае, если остальные режимы работы недоступны.
Описание сценария может быть найдено здесь.
Получение операторского делегирующего маркера доступа к ресурсу
Данный сценарий работы необходим тогда, когда на Сервисе Подписи Оператору необходимо выполнить операции с сертификатами от имени пользователя.
Сценарий является расширением сценария Авторизация с аутентификацией по сертификату и включает в себя:
- аутентификацию Оператора;
- получение маркера доступа для Оператора;
- проверка права на делегацию полномочий Оператору;
- получение делегирующего маркера доступа к ресурсам Сервиса Подписи.
Описание сценария может быть найдено здесь.