Skip to main content
Every Veriqa scenario is built from one of two mechanisms. The user experience is the same in both — a QR code on screen or a button on the phone, then one tap in a messenger — but who starts the transaction and what comes back are different.

​
Sign-in and registration

The ordinary OpenID Connect flow. Your application sends the user to /connect/authorize, the sign-in window shows a QR code (or a channel button on the phone), the user confirms in the messenger, and your application exchanges the code for tokens at /connect/token.
  • Registration happens in the same action — there is no form and no password to invent.
  • The result is an id_token with sub, auth_time and the claims you asked for; the session is yours to open.
  • Your application stays a plain OIDC client: no Veriqa package, no SDK, only configuration.
Details: Passwordless sign-in and registration, How the auth flow works.

​
Server-to-server transaction

A confirmation your backend asks for, with no sign-in and no browser redirect. The backend gets a token with the Client Credentials grant, creates the transaction with POST /api/transaction/confirmation for a declared action type, shows the user the QR code or link from the answer, and reads the outcome with GET /api/transaction/{id}/result.
  • The user reads a wording declared on your host with typed slot values — “Delete ticket A-900?”, “Buy for 4.99 EUR?” — never free text from the caller.
  • expected_identities lets only a given person confirm — for example the owner of the current session.
  • No session is created. A confirmed transaction can optionally be exchanged for the id_token of the person who confirmed.
Details: Server-to-server confirmation API.

​
How they differ

Rule of thumb. If the result should be “the user is signed in”, use sign-in. If the result should be “this action is approved” — and the action is done by your server — use the server-to-server transaction.

​
Scenarios and their mechanism

The recipes of all sign-in scenarios are collected in Integration scenarios.