OpenID Connect · Any stack · Any device · No-code · Open Source
On a computer, TV or kiosk, your users scan a QR code shown by your website or app. On a phone, they tap a button. Either way, they confirm with one tap in Telegram, WhatsApp or another messenger they already have — no passwords, no SMS codes.
Veriqa plugs into your application as a standard OIDC provider, with no frontend SDK.
Find your case — Veriqa covers sign-in, approvals and channel linking with one familiar action.
Passwordless sign-in for websites, web and desktop apps: a QR on screen, confirmation in a messenger. Registration takes the same step — no form, no password, no CAPTCHA: the messenger confirmation acts as the bot barrier.
A tool call or an access grant for an AI agent is confirmed in the user's own messenger — a surface the agent does not control, and with an audit record.
One action — two results: the user is signed in, and the product gets a live channel for notifications and service scenarios — Telegram, WhatsApp or e-mail, depending on the channel the user confirmed in.
The same familiar flow, but with no per-message charge — and with full authentication instead of code delivery.
A visitor verifies themselves via a messenger in a few seconds — the site gets a verified contact and a live channel instead of a “dead” address from a form. Works on WordPress, Bitrix, Drupal, Joomla, TYPO3 and other CMSs.
Sensitive actions, deleting important data, changing payment details, granting someone else access — confirmed with a single tap in the user's messenger.
Less friction at sign-in, a smaller spend, more security — and a live connection with the user.
Instead of a password, an SMS code and screen hops — one familiar action: opening the camera on the phone. Sign-in or registration takes about 6 seconds, and that is the whole path: pointing the camera, tapping the link and confirming in the messenger.
SMS is billed per message and gets more expensive year over year. Sign-in and approval via Veriqa aren't billed per message, and Veriqa itself is open source.
Along with the sign-in, YOUR product gets a connected messenger channel — for notifications, approvals and future service scenarios.
No install for the user and no new client-side code — Veriqa plugs into your running app through configuration.
“Forgot password” is no longer a quest: a linked trusted channel becomes a reliable recovery path, without a chain of e-mails and codes.
Veriqa stores the bare minimum: an encrypted identifier that each messenger assigns to the user. No names, no phone numbers. The data a sign-in needs appears only at the moment of the sign-in and can be kept in memory only.
What Veriqa is made of, block by block, and its main technical characteristics.
A sign-in is a transaction with an explicit state, a lifetime and a single outcome. It survives a change of device, expires on its own, is idempotent to repeats and lands in the audit trail — instead of a request left hanging somewhere between the browser and the messenger.
Telegram, WhatsApp, Email and others — switched on by configuration. A channel of your own needs no change to the core, and it does not have to be .NET: an external service in any language over HTTP, or the bot you already run, as it is. Your channels take their place in the chain alongside the built-in ones.
Any stack, standard OIDC. On .NET — a connector on top of OpenIddict. Everywhere else — a standard OIDC provider: Node, Java, Python, Go, PHP. In an IAM such as Logto it is added as an ordinary social connector in a couple of minutes.
Tokens, channels, the texts and branding of the sign-in page, policies, limits, the audit trail — all of it is configuration, with four levels of ownership, including the core, the tenant and the application, and a defined resolution order. One installation serves many projects and bots, each with its own.
The audit trail follows your rules and can be switched off entirely. Identities are always masked and tokens are written neither to the log nor to the audit — that is how it is built, not a setting you have to remember. Metrics, logs and traces come the same way.
.NET 10, shipped as NuGet packages — plugged into a running application. Clean architecture; storage in memory, EF Core (PostgreSQL, MySQL and others) or Redis. The sign-in page is plain JS — no frameworks, no external dependencies. The data does not leave your perimeter.
Veriqa complements existing solutions rather than replacing them. Here's where it's stronger — and where the honest boundary lies.
The same convenient flow — a QR on screen, confirmation from a phone — but nothing has to be set up in advance: Veriqa relies on a messenger the user already has. It works where cross-device passkeys break: Bluetooth off, a VM, remote desktop, mismatched ecosystems.
One integration layer for all channels and e-mail instead of separate widgets, plus full OIDC instead of a JS widget: tokens, sessions, account linking. And not just login — second factor, channel linking, an audit trail, and no requirement for the messenger to be installed on the surface the user signs in from.
Confirmation in a messenger is faster, isn't billed per message and lives in an app the user opens every day. And the identity is confirmed without handing over a phone number — less to leak.
From the QR you show to being signed in — in a few simple steps.
A QR code appears on the page of your site or app — that's all it takes to sign in. On a phone there is no QR code: the user sees messenger buttons instead.
They open the camera, scan the QR and tap the link. A familiar messenger opens — Telegram, WhatsApp or another.
In the messenger the user confirms the sign-in with buttons — without a password and without an SMS code. With auto-confirmation turned on, this step happens by itself.
Your auth system issues the tokens — the sign-in completes almost instantly.
Veriqa is a standard OpenID Connect provider, so it supports any stack you run: .NET, Node, Java, Python, Go, PHP — and the popular CMS platforms too. All it takes is to deploy Veriqa and connect it to your product as an OpenID connector.
Sign-in through Veriqa has been tested on WordPress, Drupal, Joomla, TYPO3 and Bitrix. These CMS platforms talk to Veriqa as to an ordinary external OIDC provider.
Veriqa can be deployed as
The auth server is embedded into your .NET application and runs in its process.
A ready-made image of the auth server that runs next to your application, inside your perimeter.
A self-contained file registered as a Windows service or a systemd unit — no Docker and no .NET runtime on the machine.
Veriqa Cloud: no deployment and no maintenance — for sites and products without their own auth infrastructure.
No. The user confirms sign-in in a messenger they already have — Telegram, WhatsApp or another supported messenger. There is no separate authenticator to install.
There are several channels, plus e-mail as a fallback everyone has. The user picks the one they have, and the list of supported messengers keeps growing.
No. Veriqa stands next to it: your auth system keeps issuing tokens and owning accounts, and Veriqa adds the trusted channel the user confirms in. For an application Veriqa is a standard OpenID Connect provider, so the stack does not matter.
No — and this question only concerns .NET. There Veriqa is a connector on top of OpenIddict, which stays the foundation of authentication. On any other stack OpenIddict is not involved at all: the application talks to Veriqa over plain OpenID Connect.
Passkeys are phishing-resistant by design — a higher security bar. Veriqa offers the same convenient flow for simpler scenarios and works where cross-device passkeys break: Bluetooth off, a VM, remote desktop.
In part. Some channels — Telegram, for example — report whether the sender is a bot, Veriqa returns that flag in the claims, and the restriction policy can cut such sign-ins off. This is not an anti-fraud system, but it is a cheap filter that works before an account is created.
With the one-tap email the user does not wait for a letter: one tap sends an already composed message from their own mailbox — on a phone that is quicker than switching to the mail app for a code. The sign-in is proven by the fact of sending from a specific address and domain, so a bot that can only forward the links and codes it receives does not get through this path.
Sign-in and approval via Veriqa aren't billed per message, unlike SMS — at noticeable sign-in volume this is direct savings.
Yes. There's a self-hosted option inside your perimeter — NuGet packages, a Docker container or an OS service with no Docker and no .NET runtime — and Veriqa Cloud; both delivery models are available.
Pick a scenario: the builder opens with it, and you start it when you are ready.
