Авторизация с неявным типом разрешения

Примечание

Данный сценарий требует интерактивного взаимодействия Пользователя с Веб-интерфейсом ЦИ DSS.

Спецификация описана в разделе 4.2 RFC6749.

Получение маркера доступа в сценарии с неявным типом разрешения может быть представлено следующей схемой:

image

  1. Запрос авторизации
  2. Авторизация пользователя
  3. Создание URI перенаправления с маркером доступа
  4. Извлечение маркера доступа

Запрос авторизации

Для инициации запроса на авторизацию клиентское приложение должно сформировать следующий запрос и отправить его на конечную точку /ouath/authorize:

Пример

https://<hostname>/<stsappname>/oauth/authorize?client_id=implicitsample&response_type=token&scope=dss&redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto&resource=https://grand-pc/signserver/rest/api HTTP/1.1

Параметры запроса:

  • client_id - идентификатор клиента OAuth, зарегистрированный на ЦИ DSS. Для регистрации клиента и его последующей конфигурации можно воспользоваться командлетами Windows PowerShell Add-DssClient и Set-DssClient соответственно.
Примечание

При регистрации клиента параметр AllowedFlow должен содержать значение Implicit.

  • response_type - в данном сценарии имеет значение token.
  • scope - области использования маркера. Должен содержать значение dss.
  • redirect_uri - зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращен запрошенный код авторизации).
Примечание

Значение параметра должно соответствовать значению адреса возврата, заданного при регистрации клиента на ЦИ.

Для случаев, в которых не планируется использование выделенного HTTP-сервиса для обработки URI перенаправления, рекомендуется использовать зарезервированный URI urn:ietf:wg:oauth:2.0:oob:auto.

  • resource - идентификатор ресурса, для доступа к которому выпускается токен. В случае Сервиса Подписи идентификатор фиксирован и имеет вид urn:cryptopro:dss:signserver:<signserverAppName>.

Если в рамках сценария необходима аутентификация клиентского приложени и известен его секрет, запрос необходимо модифицировать.

Параметр client_id в теле запроса должен был заменен на заголовок Auhtorization HTTP-запроса, имеющий значение Basic Base64(client_id:client_secret).

Авторизация пользователя

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

Создание URI перенаправления с маркером доступа

В случае успешной аутентификации Центр Идентификации подготоваливает URI перенаправления на основании данных, переданных в запросе. Адрес включает в себя маркер доступа, который должен быть извлечен из ответа сервера

Пример ответа от сервера

HTTP/1.1 302 Found
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Location: urn:ietf:wg:oauth:2.0:oob:auto#access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz...&token_type=Bearer&expires_in=300
Date: Fri, 14 Dec 2018 15:15:26 GMT
Content-Length: 0

Типовые ошибки

HTTP-код Ошибка Описание
400 invalid_client OAuth-клиент не зарегистрирован или неверно указан clientID
400 unauthorized_client OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
400 invalid_request Неверно сформирован параметр resource
500 An error has occurred Проверяющая сторона с идентификатором resource не зарегистрирована.

Извлечение маркера доступа

Для извлечения маркера доступа необходимо получить значение заголовка Location, содержащегося в HTTP-ответе от Центра Идентификации. Заголовок Location будет представлять из себя URI перенаправления, включающий в себя маркер доступа в качестве параметра.

В случае, если в качестве redirect_uri был передан валидный HTTP-адрес, маркер доступа (в Base64-формате) может быть извлечен из query-string запроса, содержащегося в Location_

В случае служебного URI urn:ietf:wg:oauth:2.0:oob:auto даанные, стоящие после знака # будут представлять из себя маркер доступа к ресурсу, закодированный в Base64 формате.