Skip to main content
A website signs a person in through a messenger the same way it would through any OpenID Connect provider: it redirects to the issuer, the person confirms in the messenger, and the browser comes back with tokens. The samples below show both sides of that sign-in. Everything lives under samples/ in the repository (veriqa.app/source) and is MIT-licensed.
Veriqa lives on the issuer side. The website itself stays a plain OIDC relying party: the client sample has no Veriqa package and would look the same against any conformant provider.

​
The samples

​
Run the pair

The issuer starts first — otherwise the client fails its discovery call.
1

Enable a channel on the issuer

The issuer ships with every channel "Enabled": false, and with none enabled the sign-in page returns no_channels_available. Enable a channel in samples/dotnet/inproc/login/appsettings.Development.json and give it credentials — a bot token is the quickest route, see Channel setup.
2

Start the issuer

Its root route returns Hello! and nothing more: the issuer has no page for a signed-in user; the sign-in starts and ends at the client.
3

Start the client and sign in

Open https://localhost:7020/. An anonymous visitor goes straight to the Veriqa sign-in page; after the confirmation in the messenger the page shows Hello, {name}!.
Both projects need a trusted local HTTPS certificate (dotnet dev-certs https --trust). Use the https address of the client: a flow started over plain HTTP sends a redirect_uri the issuer does not know.

​
Why the pair needs no configuration

The issuer already registers the second project as its client, so three values agree out of the box: redirect_uri is compared literally, without wildcards: change the client’s port and change AllowedRedirectUris with it. my-app has no ClientSecret, so it is a public client and PKCE (S256) is required of it.

​
What else the client shows

  • Cancel on the Veriqa page returns error=access_denied; the client turns it into a plain “sign-in canceled” page through AccessDeniedPath.
  • Any other failed return goes through OnRemoteFailure to a “sign-in failed” page; the error text goes to the log, not to the user.
  • GET /signout drops only the local cookie. Veriqa has no end-session endpoint, so there is no federated sign-out — see Known limitations.

​
See also