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

# Authentification

> Les trois schémas d'authentification et comment créer, utiliser et révoquer un token de compte de service.

Chaque requête authentifiée porte un en-tête `Authorization: Bearer <token>`. Solya
accepte trois types de bearer token.

## Les trois schémas

| Schéma                         | Qui l'utilise                                                         | Token                                                             |
| ------------------------------ | --------------------------------------------------------------------- | ----------------------------------------------------------------- |
| **BearerAuth**                 | L'application web (utilisateurs humains) et les intégrations externes | Un token de session NextAuth **ou** un token de compte de service |
| **Token de compte de service** | Programmes, scripts, agents IA                                        | Un token opaque `solya_sa_…` (une sorte de BearerAuth)            |
| **InternalBearerAuth**         | Services internes / cron seulement                                    | Un token statique côté serveur — non créable par l'utilisateur    |

Pour les intégrations, vous utiliserez un **token de compte de service**. Il est validé sur le même
en-tête `Authorization: Bearer` qu'une session utilisateur, donc les mêmes endpoints fonctionnent pour les deux.

## Tokens de compte de service

Un token de compte de service représente une organisation, pas une personne, et porte un ensemble explicite
de permissions.

* **Format** — `solya_sa_` suivi de 43 caractères sûrs pour les URL (≈ 52 caractères au total),
  soutenu par 256 bits d'entropie.
* **Stockage** — Solya stocke uniquement un hash SHA-256. Le token en texte brut est affiché **une seule fois**
  à la création et jamais après — copiez-le immédiatement dans votre gestionnaire de secrets.
* **Permissions** — fixées à la création. Le token ne peut faire que ce que ses permissions permettent
  (le même modèle de permission que les rôles — par ex. `inventoryPlans.view`,
  `analytics.view`, `dataPlatform.configure`).
* **Expiration** — optionnelle, jusqu'à **365 jours** ; vous pouvez aussi choisir « n'expire jamais ».
* **Limite** — jusqu'à **50** tokens actifs par organisation.

### Créer un token

<Steps>
  <Step title="Ouvrir les tokens API">
    Allez à **Paramètres → Tokens API** (nécessite une permission administrateur).
  </Step>

  <Step title="Configurez-le">
    Donnez-lui un nom, sélectionnez les permissions dont il a besoin et éventuellement une expiration.
  </Step>

  <Step title="Copiez le texte brut une seule fois">
    Copiez la valeur `solya_sa_…` immédiatement et stockez-la en toute sécurité. Vous ne pourrez plus
    la voir après — seuls ses derniers caractères sont affichés après.
  </Step>

  <Step title="Utilisez-le">
    Envoyez-le comme un bearer token (voir ci-dessous).
  </Step>
</Steps>

### Utiliser un token

```bash theme={null}
curl https://app.solya.app/api/brands \
  -H "Authorization: Bearer solya_sa_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```

### Révoquer un token

Révoquez un token depuis **Paramètres → Tokens API** à tout moment — la révocation est immédiate.
Les tokens sont aussi révoqués automatiquement si l'utilisateur qui les a créés est supprimé de
l'organisation.

## Vérifiez qui vous êtes

Appelez `GET /api/auth/whoami` pour confirmer qu'un token est valide et voir son accès effectif :

```bash theme={null}
curl https://app.solya.app/api/auth/whoami \
  -H "Authorization: Bearer solya_sa_…"
```

Pour un token de compte de service, la réponse inclut :

```json theme={null}
{
  "authKind": "api-token",
  "organizationId": "…",
  "organizationName": "…",
  "effectivePermissions": ["inventoryPlans.view", "analytics.view"],
  "tokenId": "…",
  "tokenName": "My integration",
  "tokenExpiresAt": "2026-12-31T23:59:59.000Z"
}
```

<Warning>
  Traitez les tokens `solya_sa_…` comme des mots de passe. Ne les commitez jamais dans le contrôle de source et ne les collez
  jamais dans les logs. Faites-les tourner avant expiration et révoquez tout token que vous soupçonnez d'être exposé.
</Warning>