7.4. КОНЕЧНАЯ ТОЧКА ОБЪЕКТА ЗАПРОСА
7.4. КОНЕЧНАЯ ТОЧКА ОБЪЕКТА ЗАПРОСА 
7.4.1. Вводная информация
В случае, когда клиент не желает отправлять объект запроса (см. подпункт 5.4.2.4) в качестве параметра с передачей его содержимого по значению либо потому что он слишком большой, либо потому что он содержит конфиденциальную информацию, а клиент не хочет шифровать объект запроса, объект запроса может быть отправлен по ссылке с использованием параметра <request_uri>.
В общем случае <request_uri> может быть либо URL, либо URN.
Хотя URI запроса может размещаться на стороне клиента, в спецификации ФАПИ.СЕК он должен размещаться на сервере авторизации. Преимущество сервера авторизации, на котором размещается объект запроса, состоит в том, что он не должен поддерживать исходящие запросы к определенному клиентом URI запроса и не полагается на энтропию URI для обеспечения конфиденциальности объекта запроса.
В случае если объект запроса хранится на сервере авторизации, значением <request_URI> обычно является URN.
В данном подразделе определяются методы, позволяющие конечной точке объекта запроса сервера авторизации осуществлять обмен объектом запроса на URI запроса.
7.4.2. Запрос
1 Конечной точкой объекта запроса должен быть RESTful API на сервере авторизации, который принимает подписанный объект запроса как значение компоненты <payload> HTTP-запроса.
2 Объект запроса должен подписываться для аутентификации клиента и для подтверждения факта представления клиентом объекта запроса, то есть неотказуемости.
7.4.3. Успешный ответ
1 Сервер авторизации должен проверить действительность объекта запроса и то, что параметр, идентифицирующий алгоритм подписи, не является пустым, а подпись корректна, как представлено в OIDC [11] (подраздел 6.3).
2 Если проверка прошла успешно, сервер должен сгенерировать URI запроса и вернуть в составе <payload> JSON-структуры параметры <request_URI.aud.iss> и <exp> с кодом ответа HTTP "201 Created".
3 Во избежание его угадывания значение <request_URI> должно быть сгенерировано с использованием СКЗИ. Механизм формирования <request_URI> определяется на этапе разработки сервера авторизации, исходя из его прикладных целей и задач.
4 URI запроса должен быть привязан к идентификатору клиента, который определил объект запроса в виде компоненты <payload> соответствующего запроса.
5 Поскольку URI запроса может быть повторно воспроизведен, рекомендуется сделать срок его службы коротким и однократно используемым.
6 Значения параметров компоненты <payload> JSON-структуры JWT должны быть следующими:
- <request_URI>: URI запроса, соответствующий присланному объекту запроса;
- <aud>: JSON-строка, представляющая идентификатор клиента, который послал объект запроса;
- <iss>: JSON-строка, представляющая идентификатор отправителя (issuer identifier) сервера авторизации. Если используется OAuth 2.0, значением является URI переадресации. При использовании OpenID Connect значением является значение отправителя (issuer value) сервера авторизации;
- <exp>: JSON-число, представляющее время окончания срока жизни URI запроса.
Ниже приведен пример такого ответа:
|
HTTP/1.1 201 Created
Date: Tue, 2 May 2017 15:22:31 GMT
Content-Type: application/JSON
|
|
{
"iss": "https://as.example.com/",
"aud": "s6BhdRkqt3",
"request_URI": "urn:example:MTAyODAK",
"exp": 1493738581
}
|
7.4.4. Обработка ошибок
7.4.4.1. Требуется авторизация:
- если подтверждение достоверности подписи завершилось неудачей, сервер авторизации должен вернуть HTTP ответ с кодом ошибки "401 Unauthorized".
7.4.4.2. Недействительный запрос:
- если полученный объект запроса не прошел успешно структурную/синтаксическую валидацию, сервер авторизации должен вернуть HTTP ответ с кодом ошибки "400 Bad Request".
7.4.4.3. Метод не разрешен:
- если запрос не направлен методом POST, сервер авторизации должен вернуть HTTP ответ с кодом ошибки "405 Method Not Allowed".
7.4.4.4. Длина запроса слишком велика:
- если размер запроса превышает верхнюю границу, допускаемую сервером авторизации, сервер авторизации должен вернуть HTTP ответ с кодом ошибки "413 Request Entity Too Large".
7.4.4.5. Слишком много запросов:
- если число запросов от клиента за период времени превышает границу, допускаемую сервером авторизации, сервер авторизации должен вернуть HTTP ответ с кодом ошибки "429 Too Many Requests".
7.4.5. Метаданные обнаружения поставщика OpenID
Если сервер авторизации имеет конечную точку объекта запроса и поддерживает сервис Discovery (см. подпункт 5.4.4.1), он должен включать в ответы об обнаружении следующий параметр метаданных сервера авторизации:
- <request_object_endpoint>: URL конечной точки объекта запроса, на котором клиент может осуществлять обмен объекта запроса на URI запроса.
