# Authentication

> Authenticate browser, CLI, notebook, and service clients to BisQue.

BisQue separates interactive browser sessions from public command-line and notebook clients.

## Browser applications

The BisQue web application uses OpenID Connect authorization code flow with PKCE. Provider
tokens are held server-side and the browser receives an opaque session cookie. State-changing
requests also require BisQue's browser request protections; do not treat the session cookie as
a general-purpose API credential.

## CLI and notebook clients

When the deployment enables a public OAuth client, request
`GET /api/v1/auth/client-configuration` to discover the issuer, audience, scopes, and supported
flows. A CLI can use authorization code with a loopback redirect or the OAuth device
authorization flow, then send the provider access token:

```http
Authorization: Bearer <access-token>
```

The discovery response contains public client configuration only. It never exposes the browser
client secret or another user's provider tokens.

## Local transitional authentication

An administrator can explicitly enable HTTP Basic authentication for compatible local or legacy
clients. It is disabled by default and should only be used over a trusted TLS connection. Do not
build new integrations around Basic authentication.

:::caution
Never put access tokens, passwords, or private deployment credentials in examples, notebooks,
URLs, or committed configuration.
:::