BisQue separates interactive browser sessions from public command-line and notebook clients.
Browser applications
Section titled “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
Section titled “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:
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
Section titled “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.