# Social & OAuth Providers

Federated sign-in through an external identity provider: the user proves who they are to Google or GitHub, and Sovrium trusts that result. No password is stored on your side, and offboarding a user at the identity provider offboards them from your app.

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

| Property    | Description                                                                |
| ----------- | -------------------------------------------------------------------------- |
| `providers` | Non-empty array of provider identifiers. Credentials loaded from env vars. |

## Supported Providers

Five providers are accepted. The list is a closed enum — a name outside it fails `sovrium validate` rather than being silently ignored at boot.

| Provider    | Use case                       |
| ----------- | ------------------------------ |
| `google`    | Google Workspace integration.  |
| `github`    | Developer authentication.      |
| `microsoft` | Enterprise / Azure AD.         |
| `slack`     | Workspace communication.       |
| `gitlab`    | Developer / CI-CD integration. |

## Credentials Live in the Environment

Client secrets are **never** in the schema. Your config is code — it belongs in git, gets reviewed, and ships to a mirror; a secret written there is a secret published. Each enabled provider instead reads a credential pair from the environment:

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

The general form is `{PROVIDER}_CLIENT_ID` and `{PROVIDER}_CLIENT_SECRET`, upper-cased from the provider identifier — so `microsoft` reads `MICROSOFT_CLIENT_ID` and `MICROSOFT_CLIENT_SECRET`.

:::callout
**A declared provider with no credentials will not sign anyone in.** The strategy validates against the provider list, not against the environment, so a typo'd or missing variable passes `sovrium validate` and fails at the redirect. Check each pair is set on the deploy target, not just locally.
:::

## Callback URLs

Callback (redirect) URLs are derived from `BASE_URL` — you do not configure them per provider. Register the derived URL with each provider's console, and make sure `BASE_URL` on the deploy target is the public origin users actually reach, not `localhost`.

A `BASE_URL` mismatch is the usual cause of a provider rejecting the round-trip: the redirect Sovrium sends does not match the one registered, and the provider refuses before your app is ever involved.

## Related Pages

- [Strategies Overview](/en/docs/auth-strategies) — the `strategies` array and how to choose.
- [OAuth Server](/en/docs/auth-oauth-server) — Sovrium as the authorization _server_, the inverse direction.
- [Environment Variables](/en/docs/env-vars) — `BASE_URL`, `AUTH_SECRET`, and the provider credentials.
- [Registration Control](/en/docs/auth-registration) — whether a first-time OAuth user may create an account.
- [Roles & RBAC](/en/docs/auth-roles-rbac) — the role a federated user receives.