Skip to main content
Veriqa runs inside your ASP.NET Core host and is the OpenIddict auth server. The sign-in flow is always the same: start a transaction, confirm it in a trusted channel on the phone, complete authentication in OpenIddict. To your application it is a plain OIDC Authorization Code Flow — Veriqa simply replaces the sign-in form with a confirmation in a messaging app.

​
Step by step

1

Start the transaction

The app redirects the user to /connect/authorize. Veriqa opens a transaction with the client context, a correlation id, a lifetime and the chosen channel, and renders the sign-in page with a QR code and channel buttons.
2

Confirm in the channel

The user opens the trusted channel on their phone (Telegram / WhatsApp / other channels / Email) and confirms the sign-in. The channel adapter returns the resolved identity to the transaction.
3

Completion

The desktop app learns that the sign-in is complete via a live update (SignalR) or by polling the transaction status, after which Veriqa builds a ClaimsPrincipal and hands it to OpenIddict.
4

Token issuance

OpenIddict issues an authorization code; the app exchanges it for tokens at /connect/token. From there it is standard OIDC.

​
Starting the sign-in again

A user may start a sign-in to the same application again — in a new tab or with a second scan — and reach the channel with the same account. This closes any earlier sign-ins by that account to that application still waiting for an answer, including a sign-in waiting for missing claims. Only the one that reached the channel last stays:
  • the chat gets no message about the closed sign-ins — no receipt and no “time expired” notice. If the user taps a button on a question left in the chat, they get the usual expired receipt;
  • their open pages show the expired screen and stay where they are: your application receives no error on redirect_uri for a sign-in the user has left;
  • in events, the audit trail and the transaction status such a sign-in is a failed transaction with the reason superseded_by_new_sign_in; in metrics its outcome is superseded.
Sign-ins are matched by tenant, application, channel type and the user’s identifier in that channel, at the moment the newer one is first tied to the channel account — the start in a messaging app, the link in an email, an incoming email. A sign-in that has already finished and a server-to-server confirmation are never closed this way.

​
Veriqa vs OIDC terms

​
Further reading

OIDC + Veriqa explained

Exactly where Veriqa slots into the standard OIDC flow — and what it doesn’t do.

.NET quickstart

Wire the flow into your application.