Autenticação
Métodos de autenticação suportados e como configurá-los para self-hosting
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 configuram a autenticação inteiramente por variáveis de ambiente AUTH_* — não há arquivo de configuração para montar. Veja as variáveis abaixo.
Mantenha os secrets dos provedores fora do Git. Em produção, use gerenciamento de Secrets (Kubernetes Secrets, External Secrets Operator, etc.).
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.
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.
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)
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)
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_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.