Pular para o conteúdo
supastack
Explorar a documentação
MobileExpo

For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/web/setup-oauth.md (or send Accept: text/markdown).

Configurar login OAuth

Google, Apple, GitHub, Microsoft e Twitter — um flag mais um par de cliente por fornecedor.

Perguntar sobre este guia
Abrir em

Crie e verifique uma conta real

Autenticação significa provar quem está usando o aplicativo. Inicie Postgres e execute migrações usando primeiro o guia de banco de dados e depois deixe o servidor Web em execução. Abra http://localhost:3000/auth,, escolha a inscrição por e-mail/senha, digite seu nome, e-mail e senha e envie. Mantenha EMAIL_PROVIDER=local para este primeiro teste.

Quando um fluxo solicitar um código de e-mail, abra http://localhost:3000/mail-preview em outra guia do navegador, encontre a mensagem mais recente desse endereço e copie seu código de volta no formulário de login. Solicite um novo código se ele expirar. Essas mensagens ficam na caixa de saída local; verificar repetidamente uma caixa de entrada externa não os encontrará. Saia e entre novamente para confirmar se a conta apoiada pelo banco de dados funciona.

Se a inscrição relatar uma conexão com o banco de dados ou um erro de tabela ausente, conclua a configuração do banco de dados em vez de ativar o login social. Os botões Google, GitHub, Apple, X e Microsoft precisam de seu próprio aplicativo de provedor e configurações de retorno de chamada; habilite um somente após a conclusão do guia do provedor. Better Auth é o mecanismo padrão enviado e não precisa de uma conta de autenticação paga para login de email local.

Escolhe os métodos de login ativados

A base inclui email/palavra-passe, OTP e auth social configurável. O Better Auth possui identidade e sessões, enquanto a aplicação compõe a configuração de fornecedores e a entrega transacional de OTP.

Ativa apenas os fornecedores sociais que configuraste. Os segredos de cliente de fornecedores e o segredo de auth ficam no servidor.

Liga a identidade a um workspace

Handlers autenticados resolvem o estado de sessão antes de aceder a registos do workspace. O aprovisionamento de workspace deve permanecer idempotente para que repetir um hook de ciclo de vida não crie registos de propriedade duplicados.

Verifica o comportamento de sessão

Testa login, OTPs inválidos ou expirados, consumo de utilização única, logout e acesso anónimo negado. Testes com adaptador em memória cobrem a semântica do handler; a persistência em base de produção e callbacks reais de fornecedor exigem aceitação separada.

Instalação e configuração

1. Define AUTH_SECRET com pelo menos 32 caracteres aleatórios — openssl rand -hex 32 serve.

2. Na consola de desenvolvedor de cada fornecedor, cria uma app OAuth e regista o URL de callback: {APP_URL}/api/auth/callback/<provider> no Better Auth (o AUTH_PROVIDER predefinido). Usa apps separadas para local e produção onde o fornecedor só permite um callback — docs/github-auth-setup.md percorre o fluxo GitHub de ponta a ponta.

3. Ativa o flag do fornecedor e define o seu par de cliente — AUTH_GOOGLE_ENABLED mais GOOGLE_CLIENT_ID e GOOGLE_CLIENT_SECRET, e o trio correspondente para Apple, GitHub, Microsoft ou Twitter. Ativar um flag sem as credenciais falha o arranque e nomeia a variável em falta.

4. A Microsoft é o único callback que difere por motor: /api/auth/callback/microsoft no Better Auth, /api/auth/callback/microsoft-entra-id no Auth.js.

AUTH_SECRET=<at-least-32-random-characters>
AUTH_PASSKEY_ENABLED=true
EARLY_ACCESS_INVITE_ONLY=false

AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…

AUTH_GITHUB_ENABLED=true
GITHUB_CLIENT_ID=…
GITHUB_CLIENT_SECRET=…

# AUTH_APPLE_ENABLED / AUTH_MICROSOFT_ENABLED / AUTH_TWITTER_ENABLED
# follow the same pattern:
# MICROSOFT_CLIENT_ID=…  MICROSOFT_CLIENT_SECRET=…
# TWITTER_CLIENT_ID=…    TWITTER_CLIENT_SECRET=…

# Workspace connected accounts (Settings → Connections):
# CONNECTED_X_CLIENT_ID=          CONNECTED_X_CLIENT_SECRET=
# CONNECTED_GOOGLE_CLIENT_ID=     CONNECTED_GOOGLE_CLIENT_SECRET=
# CONNECTED_MICROSOFT_CLIENT_ID=  CONNECTED_MICROSOFT_CLIENT_SECRET=

# Callbacks to register (Better Auth):
#   {APP_URL}/api/auth/callback/google
#   {APP_URL}/api/auth/callback/apple
#   {APP_URL}/api/auth/callback/github
#   {APP_URL}/api/auth/callback/twitter
#   {APP_URL}/api/auth/callback/microsoft   (Auth.js: microsoft-entra-id)

Fluxo de implementação

As contas externas do workspace são uma superfície diferente: os pares CONNECTED_X_*, CONNECTED_GOOGLE_* e CONNECTED_MICROSOFT_* alimentam Definições → Ligações, e os seus callbacks vivem em {APP_URL}/api/accounts/{x|google|microsoft}/callback. Um client id vazio deixa o fluxo de ligação desse fornecedor desativado — não reutilizes aí credenciais da app de login.

Os segredos de cliente dos fornecedores ficam só no servidor, tal como AUTH_SECRET — nunca em variáveis NEXT_PUBLIC_ ou EXPO_PUBLIC_.

Login a funcionar? Continua para Configurar IA.

Verificação e resolução de problemas

Testa o primeiro login, uma sessão de regresso, um ecrã de consentimento cancelado e um fornecedor desativado. Uma mismatch de callback é a falha habitual — o URL registado tem de corresponder exatamente a APP_URL e ao callback id do motor, e a app precisa de reinício após mudanças de env.

Perguntas frequentes

14 perguntas

O que é o supastack?

O supastack é uma base modular para construir produtos SaaS com IA. Reúne a infraestrutura comum para que possas concentrar-te nas funcionalidades próprias do teu produto.

Suporta web e mobile?

Sim. O supastack inclui apps Next.js e Expo como pontos de partida para experiências web e mobile.

Que autenticação está incluída?

O Better Auth cobre email/palavra-passe, OTP e login social. Os workspaces pessoais são aprovisionados com a conta para que os registos fiquem delimitados desde o primeiro dia.

Como é suportada a IA?

O supastack inclui IA multi-fornecedor configurável, registo de utilização, orçamentos e suporte encriptado de chaves próprias (BYOK).

Como são geridas as subscrições?

Para produtos construídos sobre o kit, a faturação Stripe, as subscrições e as permissões formam a base do acesso pago. Os segredos de fornecedor ficam no servidor.

Onde vive o código próprio do meu produto?

As funcionalidades próprias do produto ficam num codebase separado, enquanto o produto configura e integra os módulos base do supastack.

Como funciona o preço do supastack?

O kit é uma compra única com atualizações vitalícias: Uma framework por 249 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 349 $) ou Todas as frameworks (Next.js, iOS, Android) por 499 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 599 $), mais 75 $ por lugar de programador adicional. Sem subscrição do kit. O checkout neste site entrega a tua chave de licença por email, com acesso ao repo por convite GitHub.

Como é que os workspaces delimitam os meus dados?

Os registos do utilizador são delimitados por workspaceId. Identidade, permissões, utilização de IA, eventos de faturação e entradas de auditoria ficam dentro do limite do workspace pessoal.

Como funcionam os jobs em segundo plano?

O Trigger.dev é o runtime de jobs explícito. O contrato JobRunner só promete enqueue, status e cancel — a semântica de workflow permanece específica e explícita do Trigger.dev.

Como difere o email da divulgação?

O email transacional cobre fluxos de produto como avisos de conclusão de tarefas. A divulgação fria e as campanhas pertencem ao próprio produto, fora do módulo de email deste kit.

Como funcionam as compras no aplicativo móvel?

O aplicativo móvel inclui compras nativas e restauração via RevenueCat, com acesso verificado pelo servidor. Configure as contas das lojas e conclua os testes em dispositivos antes de publicar. A cobrança web permanece separada.

Onde residem as chaves dos fornecedores de IA?

As credenciais BYOK são encriptadas e ficam no servidor. As chaves são higienizadas nos logs; a utilização e os orçamentos ficam visíveis ao nível do workspace.

Quais métodos de pagamento o checkout aceita?

O checkout hospedado na Stripe aceita cartões e também pode oferecer Alipay e WeChat Pay quando essas carteiras estiverem ativadas na conta Stripe — útil para compradores na China. As autorizações de carteira são confirmadas de forma assíncrona, então a página da licença é atualizada assim que o pagamento é liquidado.

Posso solicitar um reembolso?

Depois de obter acesso ao repositório, o supastack é seu para sempre, portanto não pode ser reembolsado. Mas fique tranquilo: você recebe o código-fonte completo com atualizações vitalícias para criar e lançar produtos ilimitados para você ou seus clientes. Você apenas não pode revender o código nem redistribuir o repositório como starter kit ou modelo.

PT
Tema