> ## 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.

# Basic scenarios

> The two mechanisms every Veriqa scenario is built from — sign-in and registration, and the server-to-server transaction — and how they differ.

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](/docs/scenarios/passwordless-login),
[How the auth flow works](/docs/concepts/auth-flow).

## 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](/docs/reference/confirmation-api).

## How they differ

| | Sign-in and registration | Server-to-server transaction |
| - | - | - |
| Who starts it | The user's browser or app, by a redirect | Your backend, by an API call |
| Protocol | Standard OpenID Connect: `/connect/authorize` → `/connect/token` | Client Credentials + `POST /api/transaction/confirmation` |
| What the user confirms | The sign-in to your application | A declared action with its parameters |
| Who may confirm | Anyone — this is how a new account appears | Anyone, or only the persons named in `expected_identities` |
| What you get | `id_token` and tokens; you open the session | The outcome — `confirmed`, `declined`, `expired` or `failed`; optionally the confirming person's `id_token` |
| What your application needs | An OIDC client and its configuration | A client entry with `AllowClientCredentials`, a declared action type and a server-side call |

<Tip>
  **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.
</Tip>

## Scenarios and their mechanism

| Scenario | Mechanism | Details |
| - | - | - |
| Passwordless sign-in and registration | Sign-in | [Passwordless sign-in](/docs/scenarios/passwordless-login) |
| Sign-in with channel linking | Sign-in; server-to-server when there is no redirect | [Channel linking](/docs/scenarios/channel-linking) · [Linking from your server](/docs/scenarios/channel-linking#linking-from-your-server-without-a-sign-in) |
| Second factor and step-up | Sign-in — a repeat authorize and the `auth_time` check | [Step-up](/docs/scenarios/step-up) |
| Approving a specific action for the signed-in person | Server-to-server with `expected_identities` | [Confirmation API](/docs/reference/confirmation-api) · videos: [desktop](/docs/videos/desktop-step-up), [phone](/docs/videos/mobile-step-up), [TV](/docs/videos/tv-step-up) |
| Replacing SMS codes | Sign-in | [Replacing SMS codes](/docs/scenarios/sms-replacement) |
| Leads and feedback without CAPTCHA | Sign-in, with no session opened | [Leads without CAPTCHA](/docs/scenarios/lead-capture) · [Confirmed form submission](/docs/integrations/confirmed-form) |
| Account recovery | Sign-in through a linked channel | [Account recovery](/docs/scenarios/account-recovery) |
| Surfaces with no keyboard | Sign-in where there is a browser; server-to-server where there is none | [Sign-in surfaces](/docs/scenarios/surfaces) |
| AI agent approvals | Server-to-server | [Approvals in Claude Code](/docs/research/claude-code-approvals) |

The recipes of all sign-in scenarios are collected in
[Integration scenarios](/docs/guides/scenarios).


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