# Fournisseurs sociaux et OAuth

Connexion fédérée via un fournisseur d'identité externe : l'utilisateur prouve son identité auprès de Google ou GitHub, et Sovrium fait confiance à ce résultat. Aucun mot de passe n'est stocké de votre côté, et retirer un utilisateur chez le fournisseur d'identité le retire de votre application.

```yaml
auth:
  strategies:
    - type: oauth
      providers: [google, github, microsoft, slack, gitlab]
```

| Propriété   | Description                                                                                                 |
| ----------- | ----------------------------------------------------------------------------------------------------------- |
| `providers` | Tableau non vide d'identifiants de fournisseurs. Identifiants chargés depuis les variables d'environnement. |

## Fournisseurs pris en charge

Cinq fournisseurs sont acceptés. La liste est une énumération fermée — un nom en dehors de celle-ci échoue à `sovrium validate` au lieu d'être ignoré silencieusement au démarrage.

| Fournisseur | Cas d'usage                        |
| ----------- | ---------------------------------- |
| `google`    | Intégration Google Workspace.      |
| `github`    | Authentification des développeurs. |
| `microsoft` | Entreprise / Azure AD.             |
| `slack`     | Communication d'espace de travail. |
| `gitlab`    | Intégration développeur / CI-CD.   |

## Les identifiants vivent dans l'environnement

Les secrets client ne sont **jamais** dans le schéma. Votre configuration est du code — elle vit dans git, elle est relue, elle part vers un miroir ; un secret écrit là est un secret publié. Chaque fournisseur activé lit à la place une paire d'identifiants depuis l'environnement :

```bash
GOOGLE_CLIENT_ID=your-client-id
GOOGLE_CLIENT_SECRET=your-client-secret
GITHUB_CLIENT_ID=your-client-id
GITHUB_CLIENT_SECRET=your-client-secret
```

La forme générale est `{PROVIDER}_CLIENT_ID` et `{PROVIDER}_CLIENT_SECRET`, en majuscules à partir de l'identifiant du fournisseur — `microsoft` lit donc `MICROSOFT_CLIENT_ID` et `MICROSOFT_CLIENT_SECRET`.

:::callout
**Un fournisseur déclaré sans identifiants ne connectera personne.** La stratégie est validée contre la liste des fournisseurs, pas contre l'environnement : une variable mal orthographiée ou absente passe `sovrium validate` et échoue à la redirection. Vérifiez que chaque paire est définie sur la cible de déploiement, pas seulement en local.
:::

## URL de rappel

Les URL de rappel (redirection) sont dérivées de `BASE_URL` — vous ne les configurez pas fournisseur par fournisseur. Enregistrez l'URL dérivée dans la console de chaque fournisseur, et assurez-vous que `BASE_URL` sur la cible de déploiement est bien l'origine publique que les utilisateurs atteignent, et non `localhost`.

Une `BASE_URL` incohérente est la cause habituelle d'un fournisseur qui refuse l'aller-retour : la redirection envoyée par Sovrium ne correspond pas à celle enregistrée, et le fournisseur refuse avant même que votre application ne soit sollicitée.

## Pages connexes

- [Présentation des stratégies](/fr/docs/auth-strategies) — le tableau `strategies` et comment choisir.
- [Serveur OAuth](/fr/docs/auth-oauth-server) — Sovrium comme serveur d'autorisation, la direction inverse.
- [Variables d'environnement](/fr/docs/env-vars) — `BASE_URL`, `AUTH_SECRET` et les identifiants des fournisseurs.
- [Contrôle de l'inscription](/fr/docs/auth-registration) — si un utilisateur OAuth inconnu peut créer un compte.
- [Rôles & RBAC](/fr/docs/auth-roles-rbac) — le rôle que reçoit un utilisateur fédéré.