Skip to main content
The repository (veriqa.app/source) carries a gallery of samples under samples/. Everything there is MIT-licensed and written to be lifted into your own project.
Veriqa lives on the issuer side. An application that only signs users in stays a plain OpenID Connect relying party — no Veriqa package, no SDK. Veriqa packages appear only where the application is the issuer (embedded) or calls the confirmation API server-to-server.
Samples come in two forms:
  • Runnable — projects with their own README.md, ports and configuration. A .NET sample starts with dotnet run --project <path>; the samples outside .NET that run next to Veriqa start with docker compose up in their folder.
  • Code to copy — one file per stack with the complete client wiring. There is no project file around it: the surrounding application is yours.

​
Scenario samples

Each one shows one mechanism and nothing else. The Aspire sample and the custom-channel host share port 7320 — run them one at a time.

​
Agent harness sample

claude-code/ is a Claude Code plugin rather than a .NET project: chosen agent actions — a git push, the start of a long command cycle, a costly run with a token estimate — wait until a person approves them in the messenger, with a chain of two approvers for the costly run. See Approvals in Claude Code and the sample’s README.

​
Showcase samples

The two samples under samples/dotnet/showcase/ imitate a whole product, so the flows can be seen end to end the way a user meets them. Each is one process in three roles: the embedded issuer, the OIDC client of the browser, and the backend that creates confirmations.

Nova Stream — streaming on a TV

dotnet/showcase/streaming-tv · https://localhost:7350. Sign-in by QR from the sofa, a welcome card from the channel’s claims, recognition of a returning viewer, step-up when buying a title. Remote-control navigation, written for TV browsers (Tizen 5.5, webOS 5) and runnable behind an HTTP tunnel.

Helio — customer support

dotnet/showcase/support-desk · https://localhost:7360. A public support page, sign-in, the customer’s card, and step-up before a ticket is closed or deleted.
What they show on top of the scenario samples:
  • The person’s card from the claims the channel gave: name, picture, @username and a masked user id (Telegram), a masked phone (WhatsApp), an address (Email). Identifiers are masked on the server; the full value never reaches the browser.
  • Step-up addressed to the signed-in person. The confirmation names the identity of the current session (expected_identities), and the operation is applied only when matched_type agrees — a confirmation from another account changes nothing.
  • Receipts that differ by purpose. A sign-in’s question is replaced by “Sign-in to … confirmed ✅” (ReplacePrompt); a confirmation keeps its question and gets the receipt as a message of its own (NewMessage, stated in the backend client’s entry). See OutcomeNotice in Configuration.
  • Veriqa’s own pages, branded. The sign-in page and the confirmation window are the product’s screens; only brand, colour, theme and — for the television — a stylesheet are set through AuthPageDesign.
A Telegram bot delivers its updates to one webhook address, so with one bot token only one of the two showcase samples can take sign-ins at a time.

​
Running the .NET samples

  • .NET SDK 10.0+ and a trusted local HTTPS certificate (dotnet dev-certs https --trust).
  • Enable at least one channel and give it credentials. Every sample ships with all channels "Enabled": false; with none enabled the sign-in page answers no_channels_available. A bot token is the quickest route — see Channel setup and the sample’s own README.
  • Pairs such as login + login-client start issuer first: the client fails discovery otherwise.