¶ 1. Используемая терминология
Client Software - программная реализация клиента OAuth 2.0.
Client Instance - развернутый экземпляр части клиентского приложения.
Client Registration Endpoint - конечная точка регистрации клиента.
В терминологии OAuth2.0 представляет собой конфиденциальный ресурс, доступ к которому осуществляется через конечную точку Сервера ресурсов.
С использованием данного ресурса Клиент может зарегистрироваться на Сервере авторизации.
Client Configuration Endpoint - конечная точка конфигурации Клиента.
Специфичная для протокола OAuth2.0 конечная точка, посредством которой конфигурационная информация зарегистрированного Клиента может быть изменена.
Ссылка на данный ресурс (URI) возвращается Клиенту Сервером авторизации в ответе на запрос Клиенской информации (Client Information Response).
Registration Access Token - токен доступа, предъявляемый на конечной точке регистрации.
Токен на предъявителя (Bearer Token), предусмотренный спецификацией протокола OAuth2.0, генерируемый Сервером авторизации вследствие обращения к конечной точке регистрации Клиента, которая используется для аутентификации запрашивающей стороны, осуществляющей доступ к регистрационной информации Клиента.
Предполагается, что данный токен доступа ассоциирован с конкретным зарегистрированным Клиентом.
Initial Access Token - начальный токен доступа.
В терминологии OAuth2.0, токен доступа, который выпускается Сервером авторизации, предоставляя соответствующий начальный доступ к конечной точке регистрации Клиента.
Содержимое данного токена доступа является специфичным для конкретного сервиса и не регламентируется данной спецификацией.
Способ, которым Сервер авторизации генерирует данный токен доступа, как и способ, посредством которого конечная точка регистрации валидирует его, являются деталями реализации за пределами данной спецификации.
Software Statement - подписанный или MACed JSON Web Token (JWT), [RFC 7519], содержащий значения метаданных о Client Software виде пакета заявленных значений.
¶ 2. Software Statement
В контексте протокола динамической регистрации, используемого в рамках среды Открытых API, Software Statement может быть выпущено и подписано соответствующим субъектом, к которому есть доверие со стороны Сервера авторизации.
В качестве данных субъектов могут выступать:
- сам Сторонний поставщик (при наличии соответствующего подписного сертификата);
- удостоверяющий центр, в рамках инфраструктуры Сертификационного стенда;
- иной сервис, выполняющий функции, аналогичные отмеченному удостоверяющему центру, но за пределами Сертификационного стенда.
Если Software Statement подписано субъектом, который его выпустил, то такая структура данных называется Software Statement Assertion (SSA), или "объявленные (заявленные) доверенным субъектом свойства в рамках спецификации приложения".
SSA представляется в формате JWS (в соответствии с [RFC 7515]).
Пример SSA в формате JWT
eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGllbnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNsaWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
Декодированный JWT
{
"alg": "RS256"
}
.
{
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/"
}
¶ 3. Мета-данные Клиента
С любым OAuth Клиентом ассоциируются мета-данные, которые связаны с уникальным идентификатором Клиента (client_id), зарегистрированному на Сервере авторизации.
В состав мета-данных Клиента могут входить как строки, имеющие четкую семантику для показа пользователям системы, так и конфигурационные параметры протокола и настроек безопасности (например, перечень URI для переадресации Конечного пользователя - redirect_uri).
Мета-данные Клиента используются следующими двумя способами:
- в качестве входных параметров для запросов регистрации;
- в качестве выходных параметров в ответах на запросы регистрации и чтение регистрационных данных.
¶ 3.1 Базовые параметры мета-данных Клиента
redirect_uris - обязательный. Массив из значений redirect_uri, используемых Клиентом (им же и зарегистрированных).
Один из этих зарегистрированных redirect_uri должен в точности совпадать по значению с параметром redirect_uri, используемом в авторизационном запросе. При этом тест на соответствие производится на основании подпункта 6.2.1 спецификации [RFC 3986] (Сравнение Строк, Simple String Comparison).
response_types - опциональный. JSON массив, содержащий список значений OAuth2.0 параметров response_types, которые Клиент объявляет как возможные к использованию.
Если в силу опциональности данный параметр отсутствует, то по умолчанию Клиент может использовать только Response Type значение "code".
grant_types - опциональный. JSON массив, содержащий перечень типов разрешений, предусмотренных в рамках OAuth2.0, которые Клиент объявляет как возможные к использованию.
В рамках протокола OIDC используются следующие значения grant_types:
-
authorization_code: тип разрешения Authorization Code, описанный в разделе 4.1 спецификации протокола OAuth2.0;
-
implicit: тип разрешения Implicit Grant Type, описанный в разделе 4.2 спецификации протокола OAuth2.0;
-
refresh_token: тип разрешения Refresh Token Grant Type, описанный в разделе 6 спецификации протокола OAuth2.0.
Следующий перечень демонстрирует связь между значениями параметра response_type (тип ответа), которые могут использоваться Клиентом, и значениями параметра grant_type, которые должны быть включены в список значений параметра grant_types:
- code: authorization code
- id_token: implicit
- token id_token: implicit
- code id_token: authorization code, implicit
- code token: authorization code, implicit
- code token id_token: authorization_code, implicit
Если значения типов разрешений в явном виде не указаны в мета-данных Клиента, то единственным возможным значением, которое может быть использовано Клиентом является authorization_code.
token_endpoint_auth_method - опциональный. Запрошенный метод для аутентификации Клиента на конечной точке токена. В качестве опций может использоваться client_secret_post, client_secret_basic, client_secret_jwt, private_key_jwt, none в соответствии с описанием в Разделе 9 описания протокола OIDC Core.
Иные методы аутентификации могут быть определены в качестве расширений к приведенному списку. Если параметр не представлен в мета-данных, то по умолчанию используется client_secret_basic, т.е. схема базовой аутентификации описанная в разделе 2.3.1 описания протокола OAuth2.0 [RFC 6749].
application_type - опциональный. Тип приложения, на котором реализован Клиент.
Если не определено в мета-данных Клиента, то по умолчанию используется web. В качестве допустимых определены значения native или web.
Web-Клиенты, использующие тип разрешения Implicit Grant Type должны только регистрировать URL, используя https схему в качестве redirect_uris; они не должны использовать localhost в качестве имени хоста.
Нативные Клиенты должны исключительно регистрировать redirect_uris используя кастомные URI схемы или URI, используя https схему с localhost в качестве hostname.
Серверы авторизации могут установить дополнительные ограничения на Нативных Клиентов.
Серверы авторизации могут отвергнуть значения URI переадресации (Redirection URI), использующие http схему, кроме случая localhost для Нативных Клиентов.
Серверы авторизации должны проверить, что зарегистрированные redirect_uris соблюдают данные требования/ограничения. Это предотвращает совместное использование client_id несколькими типами Клиентов.
id_token_signed_response_alg - опциональный. Параметр alg токена JWS [JSON Web Algorithms (JWA)] является обязательным для подписания ID token, сгенерированного данному Клиенту. Значение none не должно использоваться в качестве значения параметра alg, за исключением случая, когда Клиент использует исключительно Response Type параметр запроса, который не предполагает возвращения ID token конечной точкой авторизации Сервера авторизации (такой вариант возможен только в случае использования типа Authorization Code Flow).
По умолчанию, если данный параметр не определен, используется алгоритм RS256.
Публичный ключ для валидации подписи извлекается из соответствующего JWKS, ссылка на который содержится в параметре jwks_uri мета-данных Поставщика сервиса аутентификации/авторизации в соответствии с протоколом OIDC.
request_object_signing_alg - опциональный. Параметр alg токена JWS, который должен быть использован для подписания объектов запроса, направляемых в запросе на Сервер авторизации.
Все объекты запроса, направляемые от данного Клиента должны отклоняться, если они не подписываются данным алгоритмом.
Структура объекта запроса определена в разделе 6.1 спецификации OpenID Connect Core.
Данный алгоритм должен использоваться независимо от типа передачи объекта запроса - по ссылке или по значению (в первом случае - с использованием параметра request_uri; в последнем случае - с использованием параметра request Авторизационного запроса).
token_endpoint_auth_signing_alg - опциональный. Параметр alg токена JWS, который должен использоваться для подписания JWT, используемого для аутентификации Клиента на конечной точке токена при использовании private_key_jwt или client_secret_jwt.
Все запросы токена используя данные методы аутентификации в запросах от данного Клиента должны быть отклонены, если токен JWT не подписан данным алгоритмом.
Серверам авторизации рекомедуется поддерживать алгоритм RS256 для подписания.
Значение 'none' не должно использоваться для данного параметра мета-данных. Если значение параметра не определено, то по умолчанию может использоваться любой алгоритм, поддерживаемый PR и OP.
¶ 3.2 Дополнительные параметры мета-данных Клиента
contacts, client_name, logo_uri, client_uri - опциональный. Регистрационные данные Клиента, не имеющие технического значения, т.е. не используемые в рамках протокола OAuth2.0.
policy_uri - опциональный. Адрес ресурса - URL, по которому Конечный пользователь может ознакомиться с тем, каким образом мета-данные профиля могут быть использованы.
Значение данного поля должно указывать на актуальную веб-страницу.
Поставщик сервиса аутентификации/авторизации доступа (OpenID Connect Provider в терминах OIDC протокола), должен показать адрес данного ресурса - URL, Конечному пользователю, если такой ресурс зарегистрирован в мета-данных Клиента.
tos_uri - опциональный. Адрес ресурса - URL, по которому Конечный пользователь может ознакомиться с условиями сервиса, предоставляемого Клиентом (в терминах OIDC протокола) Конечному пользователю.
jwks_uri - опциональный. Адрес ресурса - URL, по которому размещается объект JWKS, содержащий ключи, зарегистрированные данным Клиентом.
При подписании Клиентом запросов, отправляемых на Сервер, такой запрос будет содержать подписные ключи, которые должен использовать Сервер для валидации подписи под сообщениями Клиента.
jwks - опциональный. Объект JWKS, содержащий ключи, зарегистрированные данным Клиентом и передаваемые "по значению" в запросе Клиента.
Семантика jwks параметра является аналогичной той, что определена для jwks_uri - отличие заключается только в том, что jwks в данном случае передается "по значению", а не "по ссылке", как в случае с jwks_uri.
Этот параметр целесообразно использовать только теми Клиентами, которые не могут использовать jwks_uri, например, Нативные приложения, которые возможно не имеют ресурса для хостинга содержимого JWKS.
Если Клиент имеет возможность использовать jwks_uri, он не должен использовать jwks.
Слабым местом использования jwks является невозможность обеспечения ротации ключей (что без проблем реализуется с использованием jwks_uri в соответствии с порядком, определенным в OIDC Core).
Параметры jwks и jwks_uri не должны использоваться совместно.
sector_identifier_uri - опциональный. Требуется дополнительное рассмотрение на предмет целесообразности включения.
subject_type - опциональный. Values: pairwise, public. Параметр определяет subject_type, запрошенный для ответов на запросы данного Клиента.
Параметр Discovery сервиса subject_types_supported содержит перечень поддерживаемых subject_type значений для данного сервера.
id_token_encrypted_response_alg - опциональный. Параметр alg токена JWE является обязательным для шифрования ID token, выпущенного для данного Клиента.
Если мета-данными Клиента определено использование шифрование ID token ответа, то ответ Сервера авторизации будет подписан и зашифрован, что в результате определяет формат ID token как nested JWT (в соответствии со спецификацией [JSON Web Token (JWT)].
По определению, если данный параметр опущен, шифрование ID token не предусмотрено.
id_token_encrypted_response_enc - опциональный. Параметр enc токена JWE требуется для шифрования ID token, сгенерированного для данного Клиента.
Если параметр мета-данных id_token_encrypted_response_alg специфицирован для данного Клиента, то значение данного параметра по умолчанию будет A128CBC-HS256.
Если параметр id_token_encrypted_response_enc включен в мета-данные Клиента, то это автоматически требует определения значения для id_token_encrypted_response_alg.
userinfo_signed_response_alg - опциональный. Параметр alg токена JWS требуется для подписания ответов на запросы к конечной точке UserInfo.
Если данный параметр определен, то в качестве ответа будет использоваться токен JWT с соответствующей сериализацией и подписанный с использованием JWS.
userinfo_encrypted_response_alg - опциональный. Параметр alg токена JWE требуется для шифрования ответов на конечную точку UserInfo.
Если как подписание сообщения, так и его шифрование затребованы в запросе, то ответ должен быть сначата подписан, а затем зашифрован, что в результате определяет формат ID token как nested JWT.
По умолчанию, в случае, если данный параметр опущен, шифрование ответа не предполагается.
userinfo_encrypted_response_enc - опциональный. Параметр enc токена JWE требуется для шифрования ответов на запросы с конечной точки UserInfo.
Если userinfo_encrypted_response_alg определен, то по умолчанию данное значение равно A128CBC-HS256.
В тех случаях, когда параметр userinfo_encrypted_response_enc включен в мета-данные Клиента, необходимым также является определение параметра userinfo_encrypted_response_alg.
request_object_encryption_alg - опциональный. Параметр alg токена JWE, который Клиент (или Relying Party, RP, в терминах OIDC), определяет как алгоритм, который Клиент может использовать для шифрования объектов запроса (Request Object), отправляемых в запросе к Авторизационному серверу (OpenID Provider, OP, в терминах OIDC).
Этот параметр рекомендуется использовать в случаях, когда используется симметричное шифрование, поскольку это сообщает OP, что значение client_secret должно быть возвращено, и из него будет сформирован симметричный ключ.
При отсутствии данного параметра значение client_secret не возвращается.
¶ 4. Конечная точка запроса на регистрацию Клиента
Конечная точка регистрации Клиента является "защищенным ресурсом" в терминах протокола OAuth2.0, посредством которой может быть осуществлена регистрация Клиента.
Сервер авторизации (или в более широком смысле - OpenID Provider) может потребовать использования начального токена доступа (Initial access token), процедура генерации и доставки которого выходит за пределы данной спецификации.
Для того, чтобы поддержать протокол Dynamic Client регистрации конечная точка регистрации Клиента должна поддерживать запросы на регистрацию, не требующие включения стандартных токенов доступа в том значении, в котором они определены в протоколе OAuth2.0.
¶ 5. Последовательность взаимодействия при Динамической регистрации клиента
Диаграмма последовательности представляет абстрактный процесс Динамической регистрации в котором происходит успешное взаимодействие между Сторонним поставщиком (или Разработчиком) и Client Registration Endpoint Сервера ресурсов.
Взаимодействие включает следующие шаги:
-
Шаг 1 (опциональный): Сторонний поставщик (или Разработчик) получает Initial Access Token дающий доступ на Сlient Registration Endpoint Сервера ресурсов.
-
Шаг 2 (опциональный): Сторонний поставщик (или Разработчик) получает Software Statement для использования на Сlient Registration Endpoint.
-
Шаг 3: Сторонний поставщик (или Разработчик) делает HTTP-запрос методом POST на конечную точку Сlient Registration Endpoint, включая в него те параметры мета-данных, которые он (Сторонний поставщик) хочет определить в рамках процедуры регистрации, (опционально) включая Initial Access Token (если это требует Сервер авторизации).
-
Шаг 4: Сервер Авторизации возвращает Стороннему поставщику зарегистрированные метаданные, уникальный идентификатор Client Identifier (client_id), при необходимости присваивает Стороннему поставщику Client Secret (client_secret), и ассоциирует данные, присланные в запросе на регистрацию с присвоенным Стороннему поставщику идентификатором (client_id). Сервер авторизации может "доопределить" не предоставленные в запросе Клиента регистрационные мета-данные значениями "по умолчанию".
Диаграмма последовательности процесс Динамической регистрации клиента.
¶ 5.1 Запрос на регистрацию Клиента
Ниже приведены различные примеры регистрационных запросов.
Пример запроса на регистрацию Клиента с использованием Initial Access Token
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
{
"client_id": "s6BhdRkqt3",
"application_type": "web",
"redirect_uris":
["https://client.example.ru/callback",
"https://client.example.ru/callback2"],
"client_name": "My Example",
"subject_type": "pairwise",
"sector_identifier_uri":
"https://other.example.net/file_of_redirect_uris.json",
"token_endpoint_auth_method": "private_key_jwt",
// в соответствии с требованиями ФАПИ.СЕК Глава 7, на конечной точке токена Клент должен использовать метод аутентификации private_key_jwt
"jwks_uri": "https://client.example.ru/my_public_keys.jwks",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC-HS256",
}
- При взаимодействии с Сервером авторизации Клиент должен использовать TLS MA
- В случаее, если Клиент регистрируется как доверенный участник Среды Открытых банковских интерфейсов, то он должен в параметрах запроса регистрации указать параметр "client_id", присвоенный средой.
Пример запроса на регистрацию Клиента с использованием Software Statment
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
{
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"
],
"software_statement": "eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
"scope": "read write",
"example_extension_parameter": "example_value"
}
¶ 5.2 Ответ на запрос на конечную точку регистрации Клиента
По факту успешной регистрации Клиента, конечная точка регистрации Клиента возвращает значение сгенерированного идентификатора Клиента, и если предусмотрено политикой Сервера авторизации, - также возвращается и секрет Клиента (client_secret).
Эти параметры возвращаются наряду со всеми зарегистрированными мета-данными Клиента, регистрация которых была запрошена в соответствующем запросе Клиента, а также значения параметров, определенных самим Сервером авторизации в процессе регистрации Клиента.
Сервер авторизации может не принять в учет отдельные параметры из запроса Клиента на регистрацию, либо заменить значения запрошенных параметров по своему усмотрению.
Сервер авторизации не должен принимать в учет какие-либо параметры, семантику либо значения которых он не может достоверно интерпретировать.
В ответ Сервера авторизации может быть включен Регистрационный токен доступа, который может быть использован в последующем для подтверждения прав на совершение операций на конечной точке управления конфигурацией Клиента.
Успешный ответ должен использовать стандартный код ответа HTTP 201 Created и возвращать документ в формате JSON, определяя заголовок содержимого ответа как application/json.
Следующие поля и параметры мета-данных включаются в качестве включений (members) в рамках корневого JSON-объекта:
client_id - обязательный. Уникальный идентификатор Клиента. Необходимым условием является отсутствие дублирования значения client_id для двух произвольно взятых Клиентов.
client_secret - опциональный. Секретное значение, выпущенное данному Клиенту.
Одно и то же значение не может быть выпущено нескольким Клиентам.
Значение client_secret используется конфиденциальными Клиентом в процессе аутентификации на конечной точке токена, в соответствии с разделом 2.3.1 спецификации протокола OAuth2.0, а также для получения производных значений симметричного ключа шифрования в соответствии с разделом 10.2 спецификации [OpenID Connect Core 1.0].
Секретное значение client_secret не требуется и, как следствие, не присваивается Клиентам, определившим методы аутентификации token_endpoint_auth_method и private_key_jwt, за исключением случаев, когда предполагается использование симметричного шифрования.
registration_access_token - опциональный. Регистрационный токен доступа, который может быть использован на конечной точке управления конфигурацией Клиента для внесения необходимых изменений.
Получается по результату успешной регистрации Клиента.
registration_client_uri - опциональный. Ссылка на ресурс, на котором хранится конфигурация Клиента на Сервере авторизации, и доступ к которому может быть получен путем представления Регистрационного токена доступа.
client_id_issued_at - опциональный. Временная метка, определяющая момент времени, в который сгенерирован идентификатор Клиента.
Формат представления - число, представляющее собой временной промежуток между 1970-01-01T0:0:0Z (UTC) и текущим моментом, выраженный в секундах.
client_secret_expires_at - обязательный. Временная метка, определяющая момент времени, в который сгенерированное секретное значение Клиента становится не действительным по причине окончания назначенного Сервером авторизации времени использования секрета.
Пример ответа на запрос регистрации Клиента
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id": "s6BhdRkqt3",
"client_secret":
"ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
"client_secret_expires_at": 1577858400,
"registration_access_token":
"this.is.an.access.token.value.ffx83",
"registration_client_uri":
"https://server.example.ru/connect/register?client_id=s6BhdRkqt3",
"token_endpoint_auth_method":
"private_key_jwt",
"application_type": "web",
"redirect_uris":
["https://client.example.ru/callback",
"https://client.example.ru/callback2"],
"client_name": "My Example",
"subject_type": "pairwise",
"sector_identifier_uri":
"https://other.example.ru/file_of_redirect_uris.json",
"jwks_uri": "https://client.example.ru/my_public_keys.jwks",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC-HS256"
}
¶ 7. Пример потока регистрации Клиента с использованием Software Statment
Software Statment (SSA) должно быть получено Сторонним поставщиком от Сертификационного стенда.
Software Statment (SSA) подписан Сертификационным стендом JWT.
Для аутентификации Стороннего поставщика используется Mutual TLS.
Пример запроса на регистрацию Клиента
curl -X POST \
https://localhost:8243/open-banking/v3.2/register \
-H 'Content-Type: application/jwt' \
-d eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImhjZ2V4dWd1VmI1cllTWVZCc2wtYzloQlB2WSJ9
.eyJpc3MiOiJXU08yIFRQUCIsImlhdCI6MTU1NDE4NDc2NiwiZXhwIjoxNzQzNTczNTY1LCJqdGkiOiI5MjcxMz
....lrndflmZOiw9dev0UBuLOQX5X4OjFrXfgwWzLFvXCSO0rabGbLgruu5ZFWjmt9iEVq0a8oEw
Полезная нагрузка JWT. Подписывается с помощью ключа, выпущенного Сертификационным стендом с серийным номером = kid .
Декодированный JWT запроса
{
"typ": "JWT",
"alg": "RS256",
"kid": "hcgexuguVb5rYSYVBsl-c9hBPvY"
}
.
{
"iss": "APP TPP",
"iat": 1554184766,
"exp": 1743573565,
"jti": "92713892-5514-11e9-8647-d663bd873d93",
"aud": "https://localbank.ru",
"scope": "accounts payments",
"token_endpoint_auth_method": "private_key_jwt",
"grant_types": [
"authorization_code",
"refresh_token"
],
"response_types": [
"code",
"code id_token"
],
"id_token_signed_response_alg": "ES256",
"request_object_signing_alg": "ES256",
"software_id": "VgQOIBMehPnlLUQw0BFM5S",
"application_type": "web",
"redirect_uris": [
"https://openbankingru.ru/redirect"
],
"software_statement": "eyJhbGciOiJQUzI1NiIsImtpZCI6IkUxNjBBNzE0RkY4QUFBQjlBNERBRUUyRDAxQTREQ0REM0IxQjlCNEIiLCJ0eXAiOiJKV1QifQ.eyJhcHBsaWNhdGlvbl9qd2tzX2VuZHBvaW50IjoiaHR0cHM6Ly9qd2tzLnRlc3Qub3BlbmJhbmtpbmdydXNzaWEucnUvcHJvZHVjdGlvbi9qd2tzLzBiNDE0ZTRjZDAxYjQ5NTg4YTJiMjRkYTE3NjhmOTQ5IiwiYXBwbGljYXRpb25fb3JnYW5pemF0aW9uX2lkIjoiY2U0ZjA1Y2RjYmMzNGNlZGFlYTdlYjJlYjNmZGRlMTYiLCJhcHBsaWNhdGlvbl9vcmdhbml6YXRpb25faW5uIjoiMzc0ODU4ODE1OSIsImFwcGxpY2F0aW9uX29yZ2FuaXphdGlvbl9lbnRpdHkiOiLQkNCeINCi0LXRgdGCIiwiYXBwbGljYXRpb25fb3JnYW5pemF0aW9uX25hbWUiOiLQkNCeINCi0LXRgdGCIiwiYXBwbGljYXRpb25fb3JnYW5pemF0aW9uX09HUk4iOiIxMTE1NDk2NzUxMzQ3IiwiYXBwbGljYXRpb25fb3JnYW5pemF0aW9uX0tQUCI6IjExODk0NTQ1NCIsImFwcGxpY2F0aW9uX2lkIjoiMGI0MTRlNGNkMDFiNDk1ODhhMmIyNGRhMTc2OGY5NDkiLCJhcHBsaWNhdGlvbl9uYW1lIjoidGVzdC1hcHAtY2VydGlmaWNhdGVkLXYuMS4zIiwiYXBwbGljYXRpb25fcmVkaXJlY3RfdXJpcyI6Imh0dHBzOi8vbG9jYWxob3N0LnJ1L2NhbGxiYWNrIiwiYXBwbGljYXRpb25fcm9sZXMiOlsiQWNjb3VudHMiLCJQYXltZW50cyJdLCJhcHBsaWNhdGlvbl9wb2xpY3lfdXJpIjoiaHR0cHM6Ly9sb2NhbGhvc3QucnUiLCJhcHBsaWNhdGlvbl9vcmdhbml6YXRpb25fdXJpIjoiaHR0cHM6Ly9sb2NhbGhvc3QucnUiLCJhcHBsaWNhdGlvbl9sb2dvX3VyaSI6Imh0dHBzOi8vbG9jYWxob3N0LnJ1IiwiYXBpX29yZ2FuaXphdGlvbl9pZCI6ImUyYzQ3MDk0NDAxNzQ0YzI5YjQxYmNmZmI3ZmVlOGM5IiwiYXBpX29yZ2FuaXphdGlvbl9pbm4iOiI3ODI1NzA2MDg2IiwiYXBpX29yZ2FuaXphdGlvbl9lbnRpdHkiOiJudGNuIiwiYXBpX29yZ2FuaXphdGlvbl9uYW1lIjoiVm9sa292VGVzdCIsImFwaV9vcmdhbml6YXRpb25fT0dSTiI6IjEwMjc4MDkyMzc3OTYiLCJhcGlfb3JnYW5pemF0aW9uX0tQUCI6Ijc4NDEwMTAwMSIsImFwaV9pZCI6IjgwMmQyZDVlZWUwOTRhOGViYjY4Mjk0NjJhMzIwZDZmIiwiYXBpX25hbWUiOiJURVNUX0dFTkVSQVRPUl9BUElfMDIiLCJhcGlfdmVyc2lvbiI6IjEuMyIsImFwaV9wb2xpY3lfdXJpIjoiaHR0cHM6Ly93d3cuZmludGVjaC5ydSIsImFwaV90b3NfdXJpIjoiaHR0cHM6Ly93d3cuZmludGVjaC5ydSIsIm5iZiI6MTY1MjcxMzc1OSwiZXhwIjoxNjUzMzE4NTU5LCJpYXQiOjE2NTI3MTM3NTksImlzcyI6Ik9wZW5CYW5raW5nIFJ1c3NpYSJ9.dzYUA0cv3-4CPL5gst3FnMYYNqLR-5c7ggOcdTdwKYM-sjYRzXNnZlxb5CNRjOEXlQbYYrqXLzfxpA3K1R5OfAVf03mLVRomCP7zZzQXijP6EwxoSFClRC5cUBgA_yW7LSL3sE0Io5eqBBeEtgd6wBuauQB3d0eJsFbBLGKfsk9Re8xOzvddkulqfNh9XgCfz6TmN10PVXUOCXcr-mb12wfe9hH_fvS37f69wuo-mrDZD2IVpIX9cn2ANYRE270T0R_ybIR1suH-twpD3TIAn0_hMf6vxeJrgplmddd0-b1vwjpv97YkOZc7tHK-niUArd4OvzeDvZZsg0MbkuvYkQ"
}
Декодированный software_statement
{
"alg": "PS256",
"kid": "E160A714FF8AAAB9A4DAEE2D01A4DCDD3B1B9B4B",
"typ": "JWT"
}
{
"application_jwks_endpoint": "https://jwks.test.openbankingrussia.ru/production/jwks/0b414e4cd01b49588a2b24da1768f949",
"application_organization_id": "ce4f05cdcbc34cedaea7eb2eb3fdde16",
"application_organization_inn": "3748588159",
"application_organization_entity": "АО Тест",
"application_organization_name": "АО Тест",
"application_organization_OGRN": "1115496751347",
"application_organization_KPP": "118945454",
"application_id": "0b414e4cd01b49588a2b24da1768f949",
"application_name": "test-app-certificated-v.1.3",
"application_redirect_uris": "https://localhost.ru/callback",
"application_roles": [
"Accounts",
"Payments"
],
"application_policy_uri": "https://localhost.ru",
"application_organization_uri": "https://localhost.ru",
"application_logo_uri": "https://localhost.ru",
"api_organization_id": "e2c47094401744c29b41bcffb7fee8c9",
"api_organization_inn": "7825706086",
"api_organization_entity": "ntcn",
"api_organization_name": "VolkovTest",
"api_organization_OGRN": "1027809237796",
"api_organization_KPP": "784101001",
"api_id": "802d2d5eee094a8ebb6829462a320d6f",
"api_name": "TEST_GENERATOR_API_02",
"api_version": "1.3",
"api_policy_uri": "https://www.fintech.ru",
"api_tos_uri": "https://www.fintech.ru",
"nbf": 1652713759,
"exp": 1653318559,
"iat": 1652713759,
"iss": "OpenBanking Russia"
}
ППУ проверяет SSA согласно Open Banking OpenID Dynamic Client (OIDC) Registration.
ППУ регистрирует приложение Клиента используя метаданные SSA, и отвечает JSON с полезной нагрузкой, описывающей созданного Клиента.
Сторонний Поставщик может использовать клиента для доступа к Серверу ресурсов ППУ.
Пример ответа регистрации
HTTP/1.1 200 Ok
Content-Type: application/json
{
"grant_types": [
"authorization_code",
"refresh_token"
],
"software_client_name": "Open Banking test",
"supportedGrantTypes": [
"refresh_token",
"client_credentials"
],
"redirect_uris": [
"https://www.amazon.com",
"https://www.amazon.com/tt/webview/oobe/proposition"
],
"software_jwks_endpoint": "https://keystore.openbankingtest.ru/0015800001HQQrZAAX/VgQOIBMehPnlLUQw0BFM5S.jwks",
"token_endpoint_auth_method": "private_key_jwt",
"client_secret": "DMcSUBmgi4tjKktagizDuDaiCAAa",
"software_id": "VgQOIBMehPnlLUQw0BFM5S",
"software_logo_uri": "https://www.amazon.com/logo",
"scope": [
"openid",
"payments"
],
"request_object_signing_alg": "ES256",
"software_roles": [
"AISP",
"PISP"
],
"client_id": "kKcxI71dFnCtIHoM9zTZiG6U1GUa",
"id_token_signed_response_alg": "ES256"
}
Пример запроса на информацию о Клиенте
curl -X GET \
https://localhost:8243/open-banking/v1.0/register/Qib6_6Leu0eWe6Q8pMAK5YH_ZSUa \
-H 'Authorization: Bearer 5ee4f041-6901-380c-9293-c548adfa6a6e' \
-H 'Content-Type: application/jwt' -k
Пример ответа с данными Клиента
{
"scope": "accounts payments",
"grant_types": [
"authorization_code",
"refresh_token"
],
"client_secret_expires_at": 0,
"redirect_uris": [
"https://openbankingru.ru/redirect"
],
"token_endpoint_auth_method": "private_key_jwt",
"response_types": [
"code",
"code id_token"
],
"software_id": "VgQOIBMehPnlLUQw0BFM5S",
"id_token_signed_response_alg": "ES256",
"request_object_signing_alg": "ES256",
"application_type": "web",
"software_statement": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJPcGVuQmFua2luZyIsImlhdCI6MTQ5OTgwNTg0OCwiZXhwIjoxN
TMxMzQxODQ4LCJhdWQiOiJFeGFtcGxlIFRQUCIsInN1YiI6IkV4YW1wbGUgVFBQIiwiT2JUUFBJZCI6IklEQW1hem9uIiwiT2JUUFBSb2xlIjoiUElTUCJ9.RrrtJXnffK5c8rIxG3RowAsQeceH3oZQWMbpgHD78O8",
"client_id_issued_at": 1563443265,
"client_id": "kKcxI71dFnCtIHoM9zTZiG6U1GUa",
"client_secret": "DMcSUBmgi4tjKktagizDuDaiCAAa"
}
¶ 8. Один Client ID на Client Instance или на Client Software
¶ 8.1 Один Client ID на Client Software Instance
Каждый Instance (экземпляр) Сlient Software будет динамически регистрироваться и получать собственный Client ID.
Это позволяет каждому Instance иметь свой Client Secret.
Используется для нативных клиентов, которые не могут управлять значением Client Secret внутри пакета программного обеспечения, но которые могут поддерживать Client Secret на уровне Instance.
¶ 8.2 Один Client ID на все Instance представленного Client Software
Каждый Instance (экземпляр) Сlient Software будет иметь один и тот же общий Client ID.
Применяется, когда Client Instance не использует Client Secret в потоке взаимодействия.
Сервер авторизации может на каждом Instance привязать Software Statement к Client ID, и возвращать одно значение Client ID для всех запросов на регистрацию каждой части программного обеспечения.