Подключение мобильного приложения#

Совет

См. описание принципа взаимодействия мобильного приложения с Blitz Identity Provider по OIDC.

Настройки подключения#

Для подключения мобильного приложения к Blitz Identity Provider потребуются данные, полученные при его регистрации в продукте:

идентификатор, присвоенный приложению в Blitz Identity Provider (software_id);
первичный маркер доступа (Initial Access Token);
метаданные приложения (software_statement);
зарегистрированные для приложения URL возврата при авторизации;
зарегистрированные для приложения URL возврата при логауте;
зарегистрированные для приложения разрешения (scope).

В целях взаимодействия с Blitz Identity Provider приложение должно использовать следующие адреса:

URL для проведения авторизации и аутентификации:
- https://login-test.company.com/blitz/oauth/ae (тестовая среда)
- https://login.company.com/blitz/oauth/ae (продуктивная среда)
URL для получения и обновления маркера доступа:
- https://login-test.company.com/blitz/oauth/te (тестовая среда)
- https://login.company.com/blitz/oauth/te (продуктивная среда)
URL для получения данных пользователя:
- https://login-test.company.com/blitz/oauth/me (тестовая среда)
- https://login.company.com/blitz/oauth/me (продуктивная среда)
URL для динамической регистрации экземпляра мобильного приложения:
- https://login-test.company.com/blitz/oauth/register (тестовая среда)
- https://login.company.com/blitz/oauth/register (продуктивная среда)
URL для получения данных о маркере доступа:
- https://login-test.company.com/blitz/oauth/introspect (тестовая среда)
- https://login.company.com/blitz/oauth/introspect (продуктивная среда)
URL для выполнения логаута:
- https://login-test.company.com/blitz/oauth/logout (тестовая среда)
- https://login.company.com/blitz/oauth/logout (продуктивная среда)

Все эти URL, а также дополнительные сведения, размещены по адресу динамически обновляемых настроек (метаданных) каждой среды Blitz Identity Provider:

Совет

См. RFC 8414 OAuth 2.0 Authorization Server Metadata.

https://login-test.company.com/blitz/.well-known/openid-configuration (тестовая среда)
https://login.company.com/blitz/.well-known/openid-configuration (продуктивная среда)

Разработчики приложений могут не прописывать все указанные URL в конфигурации своего приложения, а использовать в настойках единую ссылку на метаданные Blitz Identity Provider.

Готовые библиотеки#

Для интеграции мобильных приложений с Blitz Identity Provider будет полезен информационный ресурс https://appauth.io/, предоставляющий SDK для iOS/Android.

Динамическая регистрация экземпляра приложения#

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

пользователь должен установить мобильное приложение;
мобильное приложение должно иметь следующие данные:
- идентификатор мобильного приложения (software_id);
- первичный маркер доступа (Initial Access Token);
- метаданные мобильного приложения (software_statement).

Мобильное приложение должно отправить HTTP-запрос методом POST в Blitz Identity Provider по адресу сервиса динамической регистрации /blitz/oauth/register.

Должны быть переданы параметры:

идентификатор мобильного приложения (software_id);
метаданные мобильного приложения (software_statement);
тип устройства, на котором работает мобильное приложение (device_type) – одно из возможных значений, представленных в таблице:

Используемые в Blitz Identity Provider маркеры

Тип устройства (`device_type`)	Описание
`iphone`	Смартфоны семейства iPhone
`ipad`	Планшеты семейства iPad
`android_phone`	Смартфоны под управлением ОС Android
`android_tab`	Планшеты под управлением ОС Android
`win_mobile`	Устройства под управлением Windows 10 Mobile

Запрос на динамическую регистрацию должен содержать заголовок Authorization с первичным маркером доступа (тип – Bearer), выданным приложению.

Пример запроса:

POST /blitz/oauth/register HTTP/1.1
Content-Type: application/json
Authorization: Bearer NINxnizbgYYQg94vEd6MjkTPxR3r2s9IAHBO92AszgTIqItY

{
   "software_id": "CSI",
   "device_type": "iphone",
   "software_statement": "eyJ0e…xQ"
}

При успешном выполнении запроса Blitz Identity Provider возвращает экземпляру мобильного приложения перечень утверждений, среди которых для дальнейшей работы необходимы следующие (их нужно защищенным образом сохранить в устройстве пользователя):

идентификатор экземпляра мобильного приложения (client_id);
секрет экземпляра мобильного приложения (client_secret);
маркер управления конфигурацией (registration_access_token);
URL управления конфигурацией (registration_client_uri).

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

{
    "grant_types": [
        "authorization_code"
    ],
    "registration_client_uri": "https://login.company.com/blitz/oauth/register/dyn~CSI~4e6904c5-ef29-4ae5-8d30-99c359b8270f",
    "scope": "openid profile",
    "registration_access_token": "eyJ0e…tw",
    "client_id": "dyn~CSI~4e6904c5-ef29-4ae5-8d30-99c359b8270f",
    "software_id": "CSI",
    "software_version": "1",
    "token_endpoint_auth_method": "client_secret_basic",
    "response_types": [
        "code"
    ],
    "redirect_uris": [
        "com.example.app:/oauth2redirect/example-provider"
    ],
    "client_secret": "3r0tt2OlyeGecWq",
    "client_secret_expires_at": 0
}

Первичный вход пользователя#

Получив пару client_id / client_secret экземпляр мобильного приложения должен провести идентификацию и аутентификацию пользователя согласно спецификациям OIDC/OAuth 2.0 и с учетом дополнительной спецификации RFC 7636 Proof Key for Code Exchange by OAuth Public Clients (мобильное приложение при взаимодействии с Blitz Identity Provider должно использовать PKCE).

Сценарий идентификация и аутентификации включает следующие шаги:

запрос на получение кода авторизации;
получение маркера доступа;
получение данных пользователя в обмен на маркер доступа.

Первичный вход пользователя в мобильное приложение должен произойти в течение 1 часа с завершения динамической регистрации в Blitz Identity Provider экземпляра мобильного приложения. Иначе client_id будет аннулирован и потребуется повторная динамическая регистрация.

Получение кода авторизации#

Для проведения аутентификации экземпляр мобильного приложения должен вызвать штатный браузер мобильной платформы и перенаправить в нем пользователя на URL Blitz Identity Provider сервиса проведения авторизации и аутентификации (/blitz/oauth/ae).

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

для iOS необходимо использовать встроенный браузер: класс SFSafariViewController или класс SFAuthenticationSession (in-app browser tab pattern);
для Android необходимо использовать встроенный браузер: функция Android Custom Tab (реализует in-app browser tab pattern).

Внимание

Использование Embedded-браузера не допускается.

В качестве параметров запроса следует указать:

client_id – идентификатор экземпляра мобильного приложения;
response_type – тип ответа (принимает значение code);
scope – запрашиваемые разрешения, должно быть передано разрешение openid и необходимые дополнительные scope для получения данных пользователя (эти scope должны быть предусмотрены метаданными);
redirect_uri – ссылка для возврата пользователя в приложение, ссылка должна соответствовать одному из указанных в метаданных значений. Чтобы после авторизации Blitz Identity Provider смог обратно вызвать мобильное приложение, следует использовать следующие схемы:
- для iOS:
  
  Совет
  
  Пример реализации – см.: openid/AppAuth-iOS
  - вариант 1 – использовать private-use URI scheme (custom URL scheme). Вид ссылок возврата: com.example.app:/oauth2redirect/example-provider (регистрируются в Info.plist ключи типа CFBundleURLTypes);
  - вариант 2 – использовать URI вида https (Universal links). Вид ссылок возврата: https://app.example.com/oauth2redirect/example-provider (используется функция «Universal links», URL регистрируются в entitlement‑файле в приложении и ассоциированы с доменом приложения). Этот способ предпочтительнее для iOS 9 и выше.
- для Android:
  
  Совет
  
  Пример реализации – см.: openid/AppAuth-Android
  - вариант 1 – использовать private-use URI scheme (custom URL scheme). Вид ссылок возврата: com.example.app:/oauth2redirect/example-provider (поддержка ссылок с помощью Android Implicit Intents, ссылки регистрируются в manifest);
  - вариант 2 – использовать URI вида https (Universal links). Вид ссылок возврата: https://app.example.com/oauth2redirect/example-provider (доступно начиная с Android 6.0, ссылки регистрируются в manifest). Этот способ предпочтительнее для Android 6.0 и выше.
state – набор случайных символов, имеющий вид 128-битного идентификатора запроса (используется для защиты от перехвата), это же значение будет возвращено в ответе – опциональный параметр;
access_type (необязательный параметр) – требуется ли приложению получать refresh_token, необходимый для получения сведений о пользователе в дальнейшем, когда пользователь будет оффлайн. Принимает значение “online”/“offline”, refresh_token предоставляется при access_type=offline. Если значение не задано, то поведение определяется настройкой, заданной для указанного приложения в Blitz Identity Provider;
code_challenge_method – метод шифрования идентификатора запроса, следует указывать “S256”;
code_challenge – зашифрованный идентификатор запроса. Идентификатор запроса (code_verifier) должен быть запомнен экземпляром мобильного приложения для последующей передачи в запрос на получение маркера доступа. Шифрованное значение вычисляется следующим образом:

code_challenge=BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

Пример запроса на получение кода авторизации (запрошена аутентификация и маркер доступа с разрешениями openid и profile, используется PKCE):

https://login.company.com/blitz/oauth/ae?scope=openid+profile
&access_type=online&response_type=code
&state=342a2c0c-d9ef-4cd6-b328-b67d9baf6a7f
&client_id=dyn~CSI~4e6904c5-ef29-4ae5-8d30-99c359b8270f
&code_challenge_method=S256&code_challenge=qjrzSW9gMiUgpUvqgEPE4
&redirect_uri=https%3A%2F%2Fapp.example.com%2Foauth2redirect%2Fexample-provider

Пример ответа со значением кода авторизации (code) и параметром state:

https://app.example.com/oauth2redirect/example-provider?code=f954nEzQ08DXju4wxGbSSfCX7TkZ1GvXUR7TzVus8fGnu4AUl-YIosgax-BLXMeQQAlasD6CN2qG_0KXK5NIjARoKykhuR9IpbuzqeFxS0&state=342a2c0c-d9ef-4cd6-b328-b67d9baf6a7f

Возможные ошибки при вызове /oauth/ae соответствуют RFC 6749 и описаны здесь.

Получение маркеров экземпляром приложения#

После получения кода авторизации экземпляр мобильного приложения должен обменять его на маркеры. Для этого экземпляр должен сформировать запрос методом POST на URL для получения маркера. Запрос должен содержать заголовок Authorization со значением Basic {secret}, где secret – это client_id:client_secret (например, dyn~CSI~4e69…Wq) в формате Base64.

Пример заголовка:

Authorization: Basic ZHluOkNTSTo…dx

Тело запроса должно содержать следующие параметры:

code – значение кода авторизации, который был ранее получен экземпляром мобильного приложения от Blitz Identity Provider;
grant_type – значение authorization_code;
redirect_uri – должно быть то же самое значение, которое было указано в запросе на получение кода авторизации;
code_verifier – идентификатор запроса, сгенерированный экземпляром мобильного приложения при запросе на получение кода авторизации.

Пример запроса:

POST /blitz/oauth/te HTTP/1.1
Authorization: Basic ZHluOkNTSTo…dx
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=FLZHS…GU
&redirect_uri=https%3A%2F%2Fapp.example.com%2Foauth2redirect%2Fexample-provider
&code_verifier=M25iVXpKU3puUjFaYWg3T1NDTDQtcW1ROUY5YXlwalNoc0hhakxifmZHag

В ответ возвращается маркер доступа и маркер идентификации.

Пример ответа с успешным выполнением запроса:

{
    "id_token": "eyJhb…J9. eyJub…0=.Ckt_dr…sQ",
    "access_token": "dO-xym…BE",
    "expires_in": 3600,
    "scope": "openid profile",
    "token_type": "Bearer"
}

После получения маркера доступа экземпляр мобильного приложения становится связанным с учетной записью пользователя. Рекомендуется, чтобы мобильное приложение предложило пользователю установить ПИН код или включить Touch ID/Face ID.

Также с помощью полученного маркера доступа приложение может запросить данные о пользователе.

Если код авторизации был уже использован, не совпал redirect_uri с ранее использованным в вызове к /oauth/ae, или истек срок действия кода, либо переданный code_verifier не соответствует code_challenge, то в качестве ответа будет возвращена ошибка.

Пример ответа с ошибкой:

{
    "error": "invalid_grant",
    "error_description": "The provided authorization grant… is invalid, expired, revoked…"
}

Возможные ошибки при вызове /oauth/te соответствуют RFC 6749 и описаны здесь.

Повторный вход пользователя#

При каждом входе пользователя в экземпляр мобильного приложения, если с устройства доступен выход в сеть Интернет, следует производить аутентификацию пользователя посредством вызова сервиса Blitz Identity Provider. В частности, при каждом входе в экземпляр мобильного приложения необходимо проверить ПИН-код пользователя или Touch ID/Face ID, после чего извлечь защищенно хранимые на устройстве client_id / client_secret и сделать запрос в Blitz Identity Provider на проведение повторного входа пользователя. Использовать полученный в ответ от Blitz Identity Provider маркер доступа для получения актуальных данных пользователя.

Запрос в Blitz Identity Provider на проведение повторного входа должен быть выполнен методом POST на URL для получения маркера (/oauth/te). Запрос должен содержать заголовок Authorization со значением Basic {secret}, где secret – это client_id:client_secret экземпляра мобильного приложения в формате Base64.

Тело запроса должно содержать параметры:

grant_type – значение client_credentials;
scope – перечень запрашиваемых экземпляром мобильного приложения разрешений.

Пример запроса:

POST /blitz/oauth/te HTTP/1.1
Authorization: Basic cG9ydGFsLmlhc2l1LmxvY2FsOnBvcnRhbC5pYXNpdS5sb2NhbA==
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=profile

В ответ возвращается маркер доступа и информация об этом маркере.

Пример ответа с успешным выполнением запроса:

{
    "access_token": "dO-xym…BE",
    "expires_in": 3600,
    "scope": "openid profile",
    "token_type": "Bearer"
}

Используя полученный маркер доступа, экземпляр мобильного приложения может запросить актуальные данные пользователя из Blitz Identity Provider, чтобы при необходимости визуализировать или обновить эти данные в устройстве.

Если пользователь в Blitz Identity Provider отозвал у экземпляра мобильного приложения право авторизации в Blitz Identity Provider, то в результате вызова Blitz Identity Provider экземпляр мобильного приложения получит ошибку.

Пример ответа с ошибкой:

{
    "error": "invalid_client",
    "error_description": "Client authentication failed…"
}

Возможные ошибки при вызове /oauth/te соответствуют RFC 6749 и описаны здесь.

Переключение или выход пользователя#

Если в мобильном приложении предусмотрена функция выхода или смены пользователя, то при вызове пользователем такой функции мобильное приложение должно также вызвать Blitz Identity Provider и удалить выпущенную для данного экземпляра мобильного приложения пару client_id / client_secret. Если это не будет сделано, то при выходе пользователя из мобильного приложения, пользователь в веб‑приложении Blitz Identity Provider Настройки безопасности все равно будет видеть, что мобильное приложение все еще привязано к его учетной записи.

Примечание

Стандартный адрес имеет вид: https://login.company.com/blitz/profile.

Чтобы удалить из Blitz Identity Provider выпущенную для экземпляра мобильного приложения пару client_id/ client_secret, мобильное приложение должно отправить в Blitz Identity Provider запрос методом DELETE на URL управления конфигурацией (registration_client_uri), полученный и запомненный мобильным приложением при вызове динамической регистрации в Blitz Identity Provider экземпляра мобильного приложения. Запрос должен содержать заголовок Authorization со значением Bearer {registration_access_token}, где registration_access_token – это маркер управления конфигурацией, также полученный и запомненный в процессе динамической регистрации. Запрос не требует указания параметров.

Пример запроса:

DELETE /blitz/oauth/register/dyn~CSI~4e6904c5-ef29-4ae5-8d30-99c359b8270f HTTP/1.1
Authorization: Bearer eyJ0e…tw

Если после удаления пары client_id / client_secret мобильное приложение сразу запросит получение новой пары client_id / client_secret, и запросит вход пользователя, то если предыдущий вход выполнялся в этой же браузерной сессии, то сработает SSO и пользователь автоматически войдет прежним аккаунтом. Обычно это нежелательное поведение для входа сразу после выхода, так как ожидается, что пользователь захочет войти под другим аккаунтом. Поэтому после выхода рекомендуется запрашивать новый вход одним из следующих способов:

При запросе кода авторизации указывать в запросе дополнительный параметр prompt=login. Тогда Blitz Identity Provider предложит текущему пользователю пройти аутентификацию, даже если активна Blitz Identity Provider сессия. Также пользователь может на странице входа выбрать Сменить аккаунт, чтобы войти под другой учетной записью.
При запросе кода авторизации указать в запросе дополнительный параметр prompt=select_account. Так Blitz Identity Provider сразу предложит пользователю выбрать аккаунт из числа запомненных или войти новым аккаунтом. Пользователю не придется дополнительно нажимать кнопку Сменить аккаунт на странице входа.

Открытие веб-ресурсов из приложения#

В некоторых мобильных приложениях разработчикам может потребоваться предусмотреть функцию открытия веб-ресурсов, также требующих идентификации/аутентификации пользователя, и использующих для этой цели Blitz Identity Provider (режим сквозной аутентификации).

При доступе к веб-ресурсу пользователь, вошедший в мобильное приложение, может столкнуться с ситуацией, что Blitz Identity Provider повторно потребует у него пройти идентификацию/аутентификацию в веб-ресурсе в результате запроса соответствующим веб‑приложением идентификации/аутентификации пользователя в Blitz Identity Provider. Чтобы такого не произошло, мобильное приложение может непосредственно перед вызовом веб-ресурса запросить в Blitz Identity Provider получение маркера доступа (access_token) на специальное разрешение (scope) с именем native.

Получить маркер доступа можно способом, описанным в Повторный вход пользователя или Получение маркеров (при наличии у приложения refresh_token).

Пример запроса:

POST /blitz/oauth/te HTTP/1.1
Authorization: Basic cG9ydGFsLmlhc2l1LmxvY2FsOnBvcnRhbC5pYXNpdS5sb2NhbA==
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=native

В ответ возвращается не только маркер доступа и информация об этом маркере, но и специальный атрибут – маркер сквозного входа css (cookie short session).

Пример ответа с получением атрибута css:

{
    "access_token": "dO-xym…BE",
     "css": "nUngQ…LA",
    "expires_in": 3600,
    "scope": "native",
    "token_type": "Bearer"
}

После этого мобильное приложение может открывать веб-ресурс. При этом в запускаемом веб-браузере мобильное приложение должно предварительно установить cookie со следующими параметрами:

имя cookie – css;
домен cookie – login.company.com;
путь (path) cookie – /blitz;
флаги HTTPOnly=true и Secure=true;
значение cookie – значение, полученное в параметре css при получении от Blitz Identity Provider маркера доступа на scope с именем native.

Если запущенный веб-ресурс в течение 300 секунд с момента запуска инициирует в Blitz Identity Provider идентификацию/аутентификацию, и cookie была корректно установлена, то Blitz Identity Provider по запросу веб-приложения проведет автоматическую сквозную идентификацию и аутентификацию пользователя под учетной записью, с которой пользователь ранее входил в экземпляр мобильного приложения, вызвавшего веб-ресурс.

Вход в приложение по QR-коду#

Вход по QR-коду может использоваться в Blitz Identity Provider как первый фактор аутентификации (альтернатива вводу логина/пароля). При выборе этого способа входа Blitz Identity Provider формирует и отображает пользователю QR-код, в котором закодирован запрос на вход (Рисунок 6). Срок действия QR-кода ограничен, а сформированный запрос является одноразовым. По истечение срока действия отображенного QR-кода пользователю предоставляется возможность запросить отображение нового QR-кода.

Закодированная в QR-коде ссылка имеет вид: QR_URL?code=b0671081-cb73-4839-8bc1-8cf020457228, например:

https://login.company.com/blitz/login/qr?code=b0671081-cb73-4839-8bc1-8cf020457228

Значение QR_URL может быть настроено таким образом, чтобы в случае наведения смартфона на QR-код с использованием стандартного приложения камеры пользователю могла быть отображена веб-страница с инструкцией по получению правильного мобильного приложения для загрузки QR-кодов или возможность вызова подходящего мобильного приложения через Universal Link.

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

Перед фотографированием QR-кода мобильным приложением пользователь должен быть залогинен в мобильное приложение с использованием Blitz Identity Provider, и мобильное приложение должно получить в Blitz Identity Provider действующий маркер доступа со scope с именем blitz_qr_auth (разрешение на проведение входа с использованием QR-кода).
При фотографировании QR-кода мобильное приложение должно отбросить значение QR_URL (оно не нужно приложению и должно быть проигнорировано) и приложение должно считать значение переданного в ссылке параметра code.
После считывания QR-кода мобильное приложение должно вызвать в Blitz Identity Provider сервис получения сведений о запросе входа, передав в сервис значение полученного кода, а также заголовок с маркером доступа и заголовок текущего языка пользователя.

Пример вызова:

curl --location --request GET 'https://login.company.com/blitz/api/v3/auth/qr/b0671081-cb73-4839-8bc1-8cf020457228' \
--header 'Accept-Language: ru' \
--header 'Authorization: Bearer eyJhb…tA'

В ответ вернется JSON, содержащий информацию об IP-адресе, операционной системе и браузере устройства, на котором пользователь пытается войти с использованием входа по QR-коду, а также имя приложения, в которое пользователь пытается войти.

Пример успешного ответа:

{
    "ip": "83.220.238.103",
    "rp_name": "User profile",
    "ip_city": "Москва",
    "browser": "Chrome 109",
    "ip_state": "Москва",
    "os": "macOS 10.15.7",
    "ip_lng": "37.6171",
    "device_type": "pc",
    "ip_lat": "55.7483",
    "ip_country": "Россия",
    "rp_id": "\_blitz_profile",
    "device_name": "macOS Big Sur (11)",
    "ip_radius": "20",
    "device": "PC"
}

Также пользователю в веб-странице будет показан экран, что ожидается подтверждение входа.

Пользователю в мобильном приложении нужно отобразить имя приложения (rp_name), IP-адрес (ip), геоданные (ip_country, ip_state, ip_city – текстовое описание адреса или показать на карте по координатам ip_lat, ip_lng), используемое устройство (device_name), браузер (browser).

Возможные значения device_type сейчас: kindle, mobile, tablet, iphone, windowsPhone, pc, ipad, playStation, unknown. Можно их использовать в визуализации сообщения или можно просто вывести имя устройства текстовой строкой из device.

Пример ответа при недействительном маркере доступа:

{
    "type": "security_error",
    "error": "bad_access_token",
    "desc": "expired_access_token"
}

Пример ответа при просроченном QR-коде:

{
    "type": "process_error",
    "error": "qr_session_expired",
    "desc": "Error while getting QR authentication session"
}

Пример ответа при несуществующем коде:

{
    "params": {},
    "desc": "Error while getting QR authentication session",
    "error": "qr_session_not_found"
}

Пример ответа при вызове по уже использованной QR-сессии (когда уже подтвердили или уже отклонили вход):

{
    "type": "process_error",
    "error": "qr_session_already_completed",
    "desc": "Error while getting QR authentication session"
}

Мобильное приложение должно отобразить пользователю полученные из JSON от Blitz Identity Provider сведения о входе, а также выбор действия: «Разрешить» или «Отклонить». В случае «Отклонить» запросить причину отклонения («Вход вызван по ошибке» или «Я не запрашивал вход»).
В зависимости от решения пользователя мобильное приложение должно вызвать в Blitz Identity Provider сервис подтверждения или отказа входа. При вызове должен использоваться маркер доступа со scope с именем blitz_qr_auth.

Пример вызова при подтверждении входа:

curl --location --request POST 'https://login.company.com/blitz/api/v3/auth/qr/5e20b01e-5c7c-4101-8292-98e6865c7bfb/confirm' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJhb…cQ'

Если успешно, то вернется HTTP 204 No Content без body. Также пользователь войдет в приложение.

Если код просрочен, то вернется:

{
    "type": "process_error",
    "error": "qr_session_expired",
    "desc": "Error while confirming QR authentication session"
}

Если код не существует, то вернется:

{
    "params": {},
    "desc": "Error while confirming QR authentication session",
    "error": "qr_session_not_found"
}

Пример ответа при недействительном маркере доступа:

{
    "type": "security_error",
    "error": "bad_access_token",
    "desc": "expired_access_token"
}

Пример ответа при вызове по уже использованной QR-сессии (когда уже подтвердили или уже отклонили вход):

{
    "type": "process_error",
    "error": "qr_session_already_completed",
    "desc": "Error while getting QR authentication session"
}

Пример вызова при отклонении входа:

curl --location --request POST 'https://login.company.com/blitz/api/v3/auth/qr/845f2334-fa6b-40c0-9a71-f57997166e39/refuse' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJhb…bQ' \
--data-raw '{
"cause_id": "mistake",
"desc": "Вход вызван по ошибке"
}'

При отклонении входа нужно обязательно передавать в теле запроса JSON с атрибутом cause_id. Рекомендуется при отклонении входа пользователем спросить причину. Если пользователь сообщит, что «передумал» (или «вызвал вход по ошибке»), то заполнить cause_id=mistake. Но если пользователь сообщит, что он не инициировал вход, то заполнить cause_id=unauthorized. Параметр desc опционален – можно указать любую текстовую строку.

В случае успешного вызова вернется HTTP 204 No Content без body. Также пользователю будет показан экран с ошибкой:

В случае если код просрочен, то вернется ошибка:

{
    "type": "process_error",
    "error": "qr_session_expired",
    "desc": "Error while refusing QR authentication session"
}

Если код не существует, то вернется:

{
    "params": {},
    "desc": "Error while refusing QR authentication session",
    "error": "qr_session_not_found"
}

Пример ответа при недействительном маркере доступа:

{
    "type": "security_error",
    "error": "bad_access_token",
    "desc": "expired_access_token"
}

Пример ответа при вызове по уже использованной QR-сессии (когда уже подтвердили или уже отклонили вход):

{
    "type": "process_error",
    "error": "qr_session_already_completed",
    "desc": "Error while getting QR authentication session"
}