---
title: Autenticação
description: Métodos de autenticação suportados e como configurá-los para self-hosting
icon: ShieldCheck
---

import Callout from "../../../../../components/ui/Callout.astro";

## O que é suportado

O deco Studio usa Better Auth e suporta:

- **Email/senha**
- **Magic link**
- **Provedores sociais** (ex.: Google, GitHub)
- **SAML SSO** (para organizações enterprise)

## Configurar autenticação (self-hosting)

Implantações self-hosted carregam um arquivo `auth-config.json` na inicialização (consulte seus guias de deploy para detalhes de montagem).

<Callout type="warning">
  Mantenha os secrets dos provedores fora do Git. Em produção, use gerenciamento de Secrets (Kubernetes Secrets, External Secrets Operator, etc.).
</Callout>

## Variáveis de ambiente principais

- `BETTER_AUTH_SECRET` (obrigatório)
- `BETTER_AUTH_URL` / `BASE_URL` (recomendado definir explicitamente em produção)

## SSO no deployment inteiro (OIDC)

Para deployments self-hosted onde todos os usuários devem autenticar através
de um único Identity Provider corporativo, dá pra configurar SSO via
variáveis de ambiente. Esse é **um SSO de deployment inteiro**: o provedor
configurado vira o padrão para todos os logins que casarem com o domínio de
e-mail configurado — sem setup por organização, sem etapa na UI de admin.
É o caminho ideal quando você está rodando o deco Studio para uma única
empresa e quer SSO obrigatório desde o primeiro login.

Se você quer SSO por organização (cada org trazendo o próprio IdP via UI de
admin), **não** defina essas envs — use o fluxo **Configurações → SSO** dentro
do app.

<Callout type="info">
  Apenas um provedor de SSO de deployment inteiro pode estar ativo por vez.
  Se as envs de Microsoft e Google estiverem definidas ao mesmo tempo,
  **Microsoft tem prioridade**.
</Callout>

### Variáveis comuns

| Variável | Descrição |
| --- | --- |
| `AUTH_SSO_DOMAIN` | Domínio de e-mail que aciona o SSO (ex.: `acme.com`). Obrigatório. |
| `AUTH_SSO_SCOPES` | Escopos separados por vírgula. Padrão: `openid,email,profile`. |

### Microsoft (Entra ID / Azure AD)

```bash
AUTH_SSO_DOMAIN=acme.com
AUTH_SSO_MS_TENANT_ID=<tenant-id-do-azure>
AUTH_SSO_MS_CLIENT_ID=<client-id-do-app-azure>
AUTH_SSO_MS_CLIENT_SECRET=<client-secret-do-app-azure>
```

No portal do Azure, registre uma aplicação e adicione a **Redirect URI**:

```
https://<seu-dominio>/api/auth/sso/callback/microsoft
```

### Google (Workspace)

```bash
AUTH_SSO_DOMAIN=acme.com
AUTH_SSO_GOOGLE_CLIENT_ID=<client-id-oauth-do-google>
AUTH_SSO_GOOGLE_CLIENT_SECRET=<client-secret-oauth-do-google>
```

No Google Cloud Console, crie um **OAuth 2.0 Client ID** do tipo *Web
application* e adicione a **Authorized redirect URI**:

```
https://<seu-dominio>/api/auth/sso/callback/google
```

Para tenants do Workspace, restrinja a tela de consentimento OAuth à sua
organização para que apenas usuários do seu domínio consigam logar.

### Login social vs. SSO

Essas envs configuram **SSO via OIDC** (plugin `@better-auth/sso`). São
diferentes dos botões de **login social** configurados via `auth-config.json`
(`socialProviders.google`, `socialProviders.github`) ou via
`AUTH_GOOGLE_CLIENT_ID` / `AUTH_GITHUB_CLIENT_ID`. Login social deixa os
usuários autenticarem com suas contas pessoais; o SSO de deployment inteiro
roteia todo mundo que casar com `AUTH_SSO_DOMAIN` para o IdP corporativo.
