Qeet Docs
Authentication

Authentication

Password, magic links, passkeys/WebAuthn, and social login — all configurable per tenant, plus an overview of enterprise SSO.

Qeet ID supports multiple first-factor authentication methods. Which ones are available is controlled per tenant by its auth policy, so each workspace can allow exactly the methods it wants.

Supported methods

Tokens issued on success

Every successful authentication returns a token pair — a short-lived ES256 access JWT plus a rotating refresh token. Verify access tokens offline against the public JWKS; exchange refresh tokens at /v1/auth/refresh. See Sessions for rotation, theft detection, and revocation.

POST/v1/auth/loginPassword login → token pair
POST/v1/auth/refreshRotate the token pair

Per-tenant auth policy

Each tenant has an auth policy controlling password rules, allowed login methods, and breached-password rejection (HaveIBeenPwned k-anonymity — off by default, fail-open).

GET/v1/tenants/{tenantID}/auth-policyRead auth policy
PUT/v1/tenants/{tenantID}/auth-policyUpdate auth policy

Brute-force protection is on by default: failed attempts trigger a per-account throttle and temporary lockout, on top of distributed IP rate limiting. See Sessions → Lockout and Rate limits.

Building the UI

You have two paths:

  • Hosted login (qeetid-login) — Qeet ID hosts the full sign-in experience (password + passkey + social + consent). Drive it from your app with @qeetid/nextjs / @qeetid/react. This is the recommended path for OIDC clients.
  • Direct API — call the REST endpoints yourself (/v1/auth/*, /v1/passkeys/*, /v1/social/*) and build your own screens.

The method pages below document the direct API; the SDK pages cover the hosted flow.

On this page