ym88659208ym87991671
Описание работы сервиса | Документация для разработчиков
Skip to main content

Описание работы сервиса

Обновлено 13 октября 2022

Данный протокол взаимодействия разработан на основе стандарта Open ID Connect.

Реализовано 7 сценариев взаимодействия:

  • Web to Web (клиент находится в браузере);
  • mWeb to App (клиент в браузере на мобильном устройстве входит на сайт Партнера через мобильное приложение Сбербанк Онлайн, если оно установлено);
  • App to webview (клиент бесшовно переходит из мобильного приложения Сбербанк Онлайн на сайт Партнера);
  • Web to Web SSO (клиент бесшовно переходит с сайта экосистемы Сбера на сайт партнера);
  • App to App (сценарий, когда у клиента установлено мобильное приложение партнера и приложение Сбербанк Онлайн);
  • App to App SSO (клиент бесшовно переходит из мобильного приложения Сбербанк Онлайн в приложение Партнера);
  • App to Web (сценарий, когда у клиента установлено мобильное приложение партнера, но не установлено мобильного приложения Сбербанк Онлайн).

Предусловия:

  • Партнер уже получил от Банка Client ID и Client Secret, зарегистрировав свое приложение в системах Банка. Инструкция по получению Client ID и Client Secret доступна в Личном кабинете.

  • Партнер получил от Банка сертификаты безопасности, настроил свое серверное ПО. Если вы еще не получили сертификаты безопасности от Банка, Вы можете узнать как это сделать в Личном кабинете.

Терминология

Аббревиатура/СокращениеОпределение
ПользовательПользователь Сбер ID
МП БанкаМобильное приложение Сбербанк Онлайн
Back БанкаБэковое программное обеспечение Банка
МП ПартнераПрограммное обеспечение Предприятия, предназначенное для работы на смартфонах, планшетах и других мобильных устройствах
Back ПартнераБэковое программное обеспечение Предприятия

Общая схема взаимодействия

Схема взаимодействия
 Описание
1Клиент нажимает кнопку входа по Сбер ID в мобильном приложении или на сайте партнера
2Мобильное приложение/сайт партнера делает запрос на свой сервер для получения nonce и state
3Сервер партнера генерирует значения nonce и state и сохраняет его в текущем сеансе пользователя (при желании можно сохранить в этой сессии адрес текущей страницы, на которой клиент нажал кнопку для входа и при успешной авторизации вернуть клиента на эту страницу)
4Сервер партнера возвращает в мобильное приложение или сайт партнера значение nonce, state и идентификатор сеанса пользователя. Если запрос на код авторизации инициирован из мобильного приложения партнера, то на этом шаге передаются параметры PKCE - code_challenge и code_challenge_method. Партнер привязывает эти значения к открытой сессии своего мобильного приложения. Подробнее см. Параметры запроса
5Мобильное приложение (или web-сайт) партнера сохраняет у себя идентификатор сеанса и делает запрос кода авторизации (мобильное приложение или web Сбербанка) с параметрами state, nonce, client_id, redirect_uri (и параметрами PKCE в случае, если запрос инициирует  мобильное приложение партнера)
6Отображение экрана аутентификации в Сбер ID
7Клиент аутентифицируется на сервере авторизации
8Отображение экрана подтверждения согласия (при отсутствии активного согласия)
9Клиент подтверждает согласие (при отсутствии активного согласия)
10Сервер авторизации выдает значение AuthCode и редиректит его на redirect_uri, включая в ответ значение state, которое пришло в запросе
11Мобильное приложение/web-сайт партнера, получив ответ, передает его на свой сервер в связке со значением текущего сеанса пользователя
12Сервер партнера должен сверить значение state из ответа с сохраненным в сеансе значением
13Если значения совпадают, то сервер партнера в рамках текущей сессии клиента делает запрос на Token Endpoint (СберAPI) для получения кода доступа (access token) -  отправляет в запросе полученное значение AuthCode, client_id, client_secret и redirect_uri (то же самое uri, которое  было отправлено в запросе на код авторизации. Если запрос на код авторизации был инициирован из мобильного приложения партнера, то необходимо в запросе на код доступа указать параметр PKCE (code_verifier)
14Token Endpoint авторизует сервер партнера, проверяет AuthCode и выдает access token и ID token
15Сервер партнера получив ID token должен проверить значение параметра nonce,  что полученное значение nonce равно значению параметра nonce, отправленного в запросе на аутентификацию
16Если значения совпадают сервер партнера может идентифицировать клиента по значению sub, полученного из ID token
17Запрос профиля клиента (userInfo)
18Передача профиля клиента
19Сервер партнера авторизует клиента у себя в сервисе и возвращает успешный ответ в мобильное приложение (зависит от бизнес-логики партнера).

Заметили ошибку?

Выделите текст и нажмите Ctrl + Enter, чтобы сообщить нам о ней