> ## Documentation Index
> Fetch the complete documentation index at: https://quintsecurity.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

<Steps>
  <Step title="Create organization">
    A new org is provisioned with a generated slug and the user's email domain.
  </Step>

  <Step title="Assign owner role">
    The first user becomes the org owner with full permissions.
  </Step>

  <Step title="Initialize defaults">
    Default preferences, token scopes, and notification settings are configured.
  </Step>
</Steps>

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](/cloud/auth-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:

<CardGroup cols={3}>
  <Card title="Deploy Tokens" icon="rocket">
    Issued per-device for agent-to-cloud communication. Prefix: `qt_dk_`
  </Card>

  <Card title="Service Tokens" icon="server">
    For CI/CD pipelines and automated integrations. Prefix: `qt_sk_`
  </Card>

  <Card title="Personal Tokens" icon="user">
    For individual API access and scripting. Prefix: `qt_pk_`
  </Card>
</CardGroup>

See [Token Hierarchy](/cloud/auth-token-hierarchy) for scoping, lifecycle, and security details.

## Invite Flow

Team growth follows a claim-based pattern:

<Steps>
  <Step title="Admin sends invite">
    An admin or owner invites a user by email with a chosen role.
  </Step>

  <Step title="Invite record created">
    A pending membership is stored with the invited email and role.
  </Step>

  <Step title="User signs up">
    The invited user creates an account (or logs in if they already have one).
  </Step>

  <Step title="Membership auto-claimed">
    On login, Quint checks for pending invites matching the user's email and activates the membership automatically.
  </Step>
</Steps>

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
```

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