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

# Authentication

> Gatelit supports three authentication schemes. Choose the one that fits your app's architecture.

Every request to the Gatelit gateway must include an `Authorization` header. The gateway reads the scheme prefix to determine how to verify the token.

## Auth modes

<Tabs>
  <Tab title="GatelitSigned">
    Your backend signs a short-lived token (60-second TTL by default) for a specific user and returns it to your frontend. The frontend includes it in every request.

    **Best for:** Frontend or mobile apps where end users interact with LLMs directly.

    ```http theme={null}
    Authorization: GatelitSigned <token>
    ```

    The token is an HMAC-SHA256 signed JWT issued by your server using the `signToken()` helper from `@gatelit/sdk`. No database lookup is required at the gateway — the signature is verified cryptographically.

    [Full guide →](/authentication/signed-tokens)
  </Tab>

  <Tab title="Bearer (OIDC)">
    Pass the user's existing OIDC session token directly. The gateway verifies it against your identity provider's JWKS endpoint.

    **Best for:** Apps where users already authenticate with Clerk, Supabase Auth, or Auth0 and you want to reuse that session.

    ```http theme={null}
    Authorization: Bearer <oidc-token>
    ```

    Supported providers: **Clerk**, **Supabase Auth**, **Auth0** (any provider that exposes a `/.well-known/jwks.json` endpoint).

    [Full guide →](/authentication/oidc-bearer)
  </Tab>

  <Tab title="GatelitKey">
    A long-lived service key tied to your org. You create and revoke keys from the dashboard.

    **Best for:** Backend services, cron jobs, agents, or any server-side caller where there is no end user.

    ```http theme={null}
    Authorization: GatelitKey <key>
    ```

    <Warning>
      Never use service keys in frontend code. They are long-lived credentials that grant full gateway access.
    </Warning>

    [Full guide →](/authentication/service-keys)
  </Tab>
</Tabs>

## Comparison

|                       | GatelitSigned             | Bearer (OIDC)                    | GatelitKey                 |
| --------------------- | ------------------------- | -------------------------------- | -------------------------- |
| **Lifetime**          | Short-lived (default 60s) | Matches OIDC token TTL           | Long-lived until revoked   |
| **Issued by**         | Your backend              | Your identity provider           | Gatelit dashboard          |
| **Best for**          | Frontend/mobile apps      | Apps with existing OIDC sessions | Backend-to-backend, agents |
| **Requires backend?** | Yes — to sign tokens      | No                               | No (but keep server-side)  |
| **Per-user**          | Yes                       | Yes                              | No                         |
| **Model restriction** | Optional — embed in token | No                               | No                         |

## Authorization header format

All three schemes use the same `Authorization` header with a different prefix:

```http theme={null}
# GatelitSigned — short-lived token from your backend
Authorization: GatelitSigned eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# Bearer — OIDC token from Clerk, Supabase Auth, or Auth0
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ii4uLiJ9...

# GatelitKey — long-lived service key from the dashboard
Authorization: GatelitKey glk_live_...
```