Ir para o conteúdo
decodecodeveloper docs
Studio → Deploy e hospedagem própria do Studio

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ávelDescrição
AUTH_SSO_DOMAINDomínio de e-mail que aciona o SSO (ex.: acme.com). Obrigatório.
AUTH_SSO_SCOPESEscopos 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.