Authentication & Authorization

How Quint handles user authentication, organization provisioning, and access control

Quint’s auth system is built on two layers: Supabase handles user identity, and Quint’s API manages organizations, roles, and tokens.

Authentication

User authentication flows through Supabase with two methods:

• Email/password — standard signup with email confirmation
• OAuth providers — Google and GitHub SSO

On successful authentication, Supabase issues a JWT. Every request to Quint’s API includes this JWT in the Authorization header. The API validates the token, resolves the user’s org membership, and enforces role-based permissions.

Organization Provisioning

Orgs are created lazily. When a user first authenticates and has no org membership, Quint automatically:

1. Create organization

   A new org is provisioned with a generated slug and the user’s email domain.

2. Assign owner role

   The first user becomes the org owner with full permissions.

3. Initialize defaults

   Default preferences, token scopes, and notification settings are configured.

No manual org creation step. Users land in a working environment immediately.

Role-Based Access Control

Every org member has one of four roles, enforced on every API call:

Role	Level	Purpose
Owner	3	Full control including billing, SSO, and org deletion
Admin	2	Manage team, tokens, policies, and fleet
Analyst	1	Investigate alerts, acknowledge events, view all data
Viewer	0	Read-only access to dashboards and sessions

See RBAC for the full permission matrix.

Token-Based Auth

Agents and integrations authenticate with tokens instead of JWTs. Three token types cover different use cases:

Deploy Tokens

Issued per-device for agent-to-cloud communication. Prefix: qt_dk_

Service Tokens

For CI/CD pipelines and automated integrations. Prefix: qt_sk_

Personal Tokens

For individual API access and scripting. Prefix: qt_pk_

See Token Hierarchy for scoping, lifecycle, and security details.

Invite Flow

Team growth follows a claim-based pattern:

1. Admin sends invite

   An admin or owner invites a user by email with a chosen role.

2. Invite record created

   A pending membership is stored with the invited email and role.

3. User signs up

   The invited user creates an account (or logs in if they already have one).

4. Membership auto-claimed

   On login, Quint checks for pending invites matching the user’s email and activates the membership automatically.

No invite links to expire or get lost. The mapping is email-based and persistent until claimed or revoked.

Architecture

Browser/CLI ──► Supabase Auth ──► JWT
                                    │
                                    ▼
                              Quint API
                              ├── Validate JWT
                              ├── Resolve org membership
                              ├── Check role permissions
                              └── Execute request

Agent/CI ──► Token (qt_dk_, qt_sk_, qt_pk_)
                    │
                    ▼
              Quint API
              ├── SHA-256 hash lookup
              ├── Validate scope
              └── Execute request

All tokens are hashed with SHA-256 before storage. The raw token is shown exactly once at creation time and cannot be retrieved afterward.