Предлагаемый сценарий для включения в Стандарт
¶ Возможность повторной аутентификации авторизованного согласия в любой момент времени
Сторонний поставщик может запросить у Пользователя повторную аутентификацию Согласия в любой момент времени для долгосрочного согласия, находящегося в состоянии «Авторизовано». Это может быть выполнено как до, так и после истечения срока действия базовых токенов.
Поставщик информационных услуг (ПИУ) должен принимать запросы от Стороннего поставщика на повторную аутентификацию согласия в любой момент времени для долгосрочного согласия, находящегося в состоянии «Авторизовано». Это включает в себя возможность до и после истечения срока действия базовых токенов.
После успешной повторной аутентификации согласия Сторонний поставщик не должен использовать токены доступа и токены обновления, которые ранее были выпущены для того же согласия.
Когда ПИУ выдает новый токен доступа и токен обновления в результате повторной аутентификации согласия, он должен аннулировать ранее выпущенные токен доступа и токены обновления для того же согласия.
¶ Простой клиентский путь
При повторной авторизации Согласия Пользователь не должен изменять параметры Согласия (выбранные счета, разрешения и даты), клиентский путь должен быть ограничен только аутентификацией Пользователя и подтверждением Согласия.
Если утерян токен доступа, но согласие действует, то при повторной авторизации согласия, нет необходимости показывать экран с деталями текущего согласия (включая привязанные счета) и кнопкой для однозначного подтверждения пользователем желания дальше передавать данные по согласию.
¶ Если утерян токен обновления
Если Согласие уже авторизовано, а токен обновления утерян или более не действителен, то необходимо повторно авторизовать Согласие.
Восстановление токена происходит путем вызова методов GET/ authorize (получение кода авторизации) и POST/ token (создание ресурса - токена обновления).
Ниже приведены диаграмма последовательности с учетом сценария авторизации!
¶ Повторная аутентификация Согласия, инициируемая Сторонним поставщиком
Данный сценарий является концептуальным и не должен рассматриваться для применения в текущих реализациях
ППИУ может использовать повторную аутентификацию Согласия на стороне СПИУ.
(Примечание. Участники взаимодействия в индивидуальном порядке, определяют обязанности Стороннего поставщика по авторизации Пользователя, методы аутентификации, разрешение споров и т. д.)
Сторонний поставщик, интегрированный с несколькими ППИУ с возможностью повторной аутентификации согласия, может предоставить Пользователю упрощенный клиентский путь за счет строгой аутентификации Пользователя один раз и использования этой аутентификации для обновления токенов доступа с несколькими ППИУ.
Для повторной аутентификации согласия необходимо использовать JWT в качестве авторизации предоставление доступа как определено в RFC 7523 «JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants», раздел «2.1. Using JWTs as Authorization Grants». Сервер авторизации ППИУ, который поддерживает данное свойство, должен заявлять о нем в разделе поддерживаемых типов доступа на своей конечной точки «дискавери» (well-known). Формализованным наименованием типа доступа «jwt-bearer» является значение «urn:ietf:params:oauth:grant-type:jwt-bearer».
Ниже приведены диаграмма последовательности с учетом сценария авторизации!
.
Сценарий 1. При вызове метода GET/ authorize (а затем POST/ token) при повторной аутентификации, Сторонний поставщик должен создать согласие и авторизовать его Пользователем на стороне ППИУ, используя тип доступа Authorization Code. В результате этого шага у ППИУ будет Согласие, привязанное к конкретному Пользователю.
Чтобы выполнить повторную аутентификацию, Сторонний поставщик предоставляет Пользователю авторизацию в контексте согласия, которое должно быть повторно аутентифицировано.
Сценарий 2. При использовании Client Credentials Flow необходимо вызвать POST/ token
¶ Регистрация Клиента (Приложения)
Сторонний поставщик, при интеграции с ППИУ должен регистрировать свое приложение с поддержкой типа доступа «urn:ietf:params:oauth:grant-type:jwt-bearer». ППИУ может предоставлять данный тип доступа только тем Приложениям, по которым у них есть договоренность со Сторонним поставщиком.
¶ Использование jwt-bearer для повторной аутентификации
Для использования «jwt-bearer» при повторной аутентификации, Сторонний поставщик должен создать согласие и авторизовать его Пользователем на стороне ППИУ используя тип доступа Authorization Code. В результате этого шага у ППИУ будет Согласие, привязанное к конкретному Пользователю.
Чтобы выполнить повторную аутентификацию, Сторонний поставщик предоставляет Пользователю авторизацию в контексте согласия, которое должно быть повторно аутентифицировано.
¶ Запрос к конечной точке токена
Сторонний поставщик должен обращаться к конечной точке токена сервера авторизации ППИУ с типом доступа urn:ietf:params:oauth:grant-type:jwt-bearer. Значение используется как значение параметра «grant_type» в запросе к конечной точке токена.
Заголовок JWT должен представлять следующие параметры:
- alg
- kid
При установке параметров тела JWT необходимо выполнять следующие правила:
- значение
issдолжно соответствовать client_id приложения Стороннего поставщика - значение
subдолжно соответствовать intent_id (в случае СПИУ consent_id), которое требует повторной авторизации. - значение
audдолжно соответствовать URL конечной точки токена сервера авторизации - должен содержать элементы (
jti,exp,nbf,iat)
Пример
Ниже приведен ненормативный пример вызова конечной точки токена для инициирования типа доступа jwt-bearer.
POST /sandbox/as/aft/connect/token HTTP/1.1 Host: sb-as.openbankingrussia.ru Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&scope=accounts
&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.......
Декодированное значение JWT assertion:
{
"alg": "PS256",
"kid": "512DF60009ADFBA042A20980C8AC7XXX"
}
{
"iss": "f917546e7a194df9bd02342632cd944f",
"sub": "{consent-id-uuid-identificator}",
"aud": "https://sb-as.openbankingrussia.ru/sandbox/as/aft/connect/token",
"exp": 1658863062,
"nbf": 1573455767,
"iat": 1573455767,
"jti": "90729a20-5eee-4035-9113-5c731e9e2c63"
}
¶ Простой Клиентский путь
Взаимодействие Пользователя с повторной аутентификацией Согласия должно иметь простой клиентский путь, не содержащий лишних шагов.
Пример клиентского пути с реавторизацией согласия на стороне СПИУ (скачать рисунок)
Предлагаемый клиентский путь необходимо согласовать и для пилотирования (с НС АФТ), и для боевой среды (с ЦБ). Для пилотирования необходимо вносить правки в ТПКО и согласовывать с НС АФТ.