> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Как завершается вход

> Три способа узнать, что подтверждение состоялось: возврат по redirect, живой статус по SignalR и опрос статуса транзакции — и чем канал Email отличается от остальных.

Подтверждение происходит на телефоне, а инициатор ждёт на другом устройстве. Отсюда вопрос,
который на обычном OIDC-провайдере не возникает: **как инициатор узнаёт, что всё случилось?**

Способов три, и они не альтернативы друг другу, а разные уровни: возврат по redirect — обязателен
всегда, живой статус и опрос — про то, что показывать пользователю, пока он ждёт.

## 1. Возврат по `redirect_uri` — основной путь

Итог входа приезжает так же, как в любом OIDC: браузер инициатора возвращается на `redirect_uri` с
кодом авторизации, приложение меняет его на токены. Ничего специфичного для Veriqa здесь нет.

Этого достаточно для веб-приложения на десктопе: страница входа сама доводит пользователя до
возврата.

<Note>
  В query возврата приезжает `iss` (RFC 9207). Строгому relying party стоит сверять его со своим
  ожидаемым issuer — это дешёвая защита от подмены провайдера.
</Note>

## 2. Живой статус — SignalR

Пока человек берёт телефон, сканирует код и нажимает кнопку, инициатор может показывать состояние:
«ждём подтверждения», «подтверждено», «отклонено». Для этого есть хаб `/hubs/auth` — страница входа
Veriqa использует его сама, и он же доступен вашей поверхности.

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

## 3. Опрос статуса — запасной путь

Там, где WebSocket недоступен (жёсткий прокси, ограниченная сеть, встроенное устройство), остаётся
опрос:

```http theme={null}
GET /api/transaction/{id}/status
```

<Note>
  Этот эндпоинт — про опрос состояния текущего входа. Подтверждение, которое создаёт ваш сервер,
  идёт отдельным входом: `POST /api/transaction/confirmation` создаёт транзакцию подтверждения
  (приложение аутентифицируется по client credentials и получает `transaction_id` с точкой входа для
  пользователя), а `GET /api/transaction/{id}/result` отдаёт её исход (токен приложения
  обязателен). Полный контракт — в [API серверного подтверждения](/docs/ru/reference/confirmation-api).

  Если в запросе создания передать `include_channel_entries: true`, ответ дополнительно несёт
  `channel_entries` — deep link с QR по каждому доступному каналу — рядом с единственным
  `channel_entry`, который остаётся прежним. Какие каналы попадут в список и в каком порядке, задаёт
  конфигурация показа каналов (включая запись `ui_config`), а не ваш запрос. Канал без адреса, который
  можно открыть, — например Email в Pull-режиме — в список не попадает, а если подтверждение
  настроено на веб-странице, массив пуст. Показать ли один вход из списка — решаете вы.
  `response_valid_until` тогда — самый ранний момент среди всех отданных входов.

  После исхода `confirmed` клиент, которому это разрешил интегратор, может получить и `id_token`
  подтвердившего — см. [привязку с сервера](/docs/ru/scenarios/channel-linking#привязка-с-сервера-без-входа).
</Note>

## Канал Email ведёт себя иначе

Важное для интегратора отличие: **шаг веб-подтверждения зависит от канала**.

* на **Telegram** возврат `/connect/authorize/callback` сразу отдаёт редирект: человек уже нажал
  «да» в мессенджере;
* на **Email** тот же адрес показывает страницу «Подтвердите вход» с формой — без её отправки кода
  не будет.

Причина: клик по ссылке из письма не доказывает, что за браузером тот же человек. Но
интегратор, отладивший поток на Telegram, на Email упирается в «лишний» экран — это свойство
канала, а не сбой.

## Что после подтверждения

Поведение окна после успеха настраивается (закрыть, показать сообщение, автоматически продолжить)
на стороне конфигурации входа — набором настроек, который владелец проекта или интегратор
назначает клиенту. Само получение токенов от этого не зависит.

## Дальше

<CardGroup cols={2}>
  <Card title="Поверхности входа" icon="tv" href="/docs/ru/scenarios/surfaces">
    Чем ТВ и киоск отличаются от десктопа.
  </Card>

  <Card title="Диагностика" icon="stethoscope" href="/docs/ru/guides/troubleshooting">
    Что означают отказы на callback.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.