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

# Sign-in on a website via a messenger

> Samples of website sign-in through a messenger: the issuer with Veriqa embedded, a stock OIDC client, the same sign-in under .NET Aspire and the client code for an external issuer.

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](https://veriqa.app/source)) and is MIT-licensed.

<Note>
  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.
</Note>

## The samples

| Path | Side | What it shows | Form |
| - | - | - | - |
| `dotnet/inproc/login` | issuer | Veriqa embedded in the application (`AddVeriqaAuthServer` / `MapVeriqaAuthServer`); the issuer runs inside the process | runnable · `https://localhost:7300` |
| `dotnet/inproc/login-client` | client | A stock ASP.NET Core relying party (`AddCookie` + `AddOpenIdConnect`, Authorization Code + PKCE) | runnable · `https://localhost:7020` |
| `dotnet/aspire/login` | issuer | The same embedded issuer under .NET Aspire: the transaction store is an orchestrated resource (needs Docker) | runnable · `https://localhost:7320` |
| `dotnet/remote/login` | client | A client of an external issuer — self-hosted or Veriqa Cloud | code to copy |
| `java/Application.java` | client | The same client on Spring Security OAuth2 Client | code to copy |
| `node/index.ts` | client | The same client on `openid-client` + Express | code to copy |
| `python/main.py` | client | The same client on Authlib + FastAPI | code to copy |

## Run the pair

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

<Steps>
  <Step title="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](/docs/guides/channels).
  </Step>

  <Step title="Start the issuer">
    ```bash theme={null}
    dotnet run --project samples/dotnet/inproc/login
    ```

    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.
  </Step>

  <Step title="Start the client and sign in">
    ```bash theme={null}
    dotnet run --project samples/dotnet/inproc/login-client
    ```

    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}!`.
  </Step>
</Steps>

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:

| Client | Issuer (`Veriqa:OpenIddict:Clients[]`) |
| - | - |
| `Oidc:Authority` = `https://localhost:7300` | the issuer's own address |
| `Oidc:ClientId` = `my-app` | `ClientId` |
| `CallbackPath` = `/signin-oidc` on port 7020 | an `AllowedRedirectUris` entry |

`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](/docs/reference/limitations).

## See also

* [.NET quickstart](/docs/quickstart/dotnet) — the same wiring, step by step
* [How the auth flow works](/docs/concepts/auth-flow)
* [Passwordless sign-in and registration](/docs/scenarios/passwordless-login)
* [Video: sign-in on a website](/docs/videos/web-sign-in)


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