Qeet ID
An open-source, self-hostable, passkeys-first identity platform — OIDC + SAML provider, SCIM, RBAC, and a tamper-evident audit log, with no SSO tax.
Qeet ID is an open-source, self-hostable identity platform. It gives you the developer experience of a modern CIAM (passkeys, social login, hosted login, five first-party SDKs) and the enterprise model of a B2B identity provider (SAML, SCIM, LDAP, organizations) — in one binary, without paywalling SSO behind an "enterprise" tier.
Status
Qeet ID is pre-1.0 with a July 2026 GA target. The platform backend, admin/login frontends, and SDKs are implemented and tested. A few items are external/ops dependencies (KMS key material, deliverability domains, conformance runs) rather than code gaps — those are flagged inline throughout the docs.
What you can build
Authenticate users
Password, magic links, passkeys/WebAuthn, and social login — configurable per tenant.
Add MFA & step-up
TOTP, email/SMS OTP, WebAuthn as a second factor, and step-up on sensitive actions.
Be an SSO provider
Stand up an OIDC and SAML IdP: hosted login, consent, device grant, M2M.
Enterprise federation
Consume external IdPs (SAML SP), provision via SCIM Users + Groups, bind LDAP.
Authorize requests
RBAC with a single-call /check, group roles, ABAC, and explainable authz.
Prove what happened
A SHA-256 hash-chained, append-only audit log with a /verify endpoint.
Why Qeet ID
- Both an OIDC IdP and a SAML IdP, with SCIM Users + Groups — full enterprise federation, open-source and not behind an SSO tax.
- Tamper-evident, hash-chained audit with a
/verifyintegrity endpoint — provable audit most CIAM platforms don't offer. - Security defaults on by default — refresh-token theft detection, per-account lockout, breached-password rejection (HIBP k-anonymity), and a production boot-gate that refuses to start with insecure defaults.
- Five first-party SDKs — TypeScript, Next.js, React, Go, and Python — over a 100%-covered OpenAPI spec guarded in CI.
- Self-hostable with a real Helm chart and DR runbook. You own your data.
Tokens & keys at a glance
Two auth schemes — don't mix them
- Server-to-server API calls use an API key:
Authorization: ApiKey qk_…. - User access tokens are ES256 JWTs verified against the public JWKS:
Authorization: Bearer <jwt>.
API keys never go in the browser. The bearer scheme on user/service routes is for the JWT, not the API key.
Start here
Quickstart
Install an SDK, init with an API key, and protect a route in minutes.
Core concepts
Tenants, users, sessions, principals, roles — the model everything sits on.
API reference
142 paths from the OpenAPI spec — auth schemes, errors, and pagination.
SDKs
TypeScript, Next.js, React, Go, and Python — with JWKS session verification.