Configurar OAuth Providers

Pré-requisitos

Antes de configurar qualquer provider OAuth, você precisa:

• Ter criado um projeto no dashboard (app.superdb.com.br).
• Só se você for usar credenciais próprias: ter registrado uma aplicação OAuth no console do provider (Google Cloud Console, GitHub Developer Settings, Apple Developer). No modo gerenciado (padrão) não precisa de nada disso — veja abaixo.
• Conhecer a Redirect URI do SuperDB para configurar no provider:

https://auth.superdb.com.br/auth/v1/callback/google
https://auth.superdb.com.br/auth/v1/callback/github
https://auth.superdb.com.br/auth/v1/callback/apple

Dois modos: gerenciado ou credenciais próprias

Google e GitHub aceitam os dois modos. Apple só gerenciado. Microsoft ainda não está disponível.

Google OAuth (passo a passo)

Google é o provider mais comum. O fluxo abaixo cobre o setup completo.

1. Criar credenciais no Google Cloud Console

1. Acesse console.cloud.google.com/apis/credentials.
2. Clique em Criar credenciais → ID do cliente OAuth.
3. Tipo: Aplicativo da Web.
4. Em URIs de redirecionamento autorizados, adicione: https://auth.superdb.com.br/auth/v1/callback/google
5. Copie o Client ID e o Client Secret.

2. Configurar no dashboard

1. Acesse app.superdb.com.br → seu projeto → Autenticação.
2. No cartão Google, clique em Configurar.
3. Marque usar minhas próprias credenciais e cole o Client ID e o Client Secret. (Se quiser apenas testar, deixe desmarcado — o modo gerenciado funciona na hora, sem passo 1.)
4. Clique em Salvar.
5. Na seção URLs de redirecionamento, cadastre para onde o usuário volta após o login (ex.: https://meuapp.com.br/auth/callback ou o deep link meuapp://auth). Sem isso o login volta para / sem erro.

3. Para aparecer a SUA marca na tela do Google

Como saber em que projeto o seu client nasceu: o Client ID começa com o número do projeto — 123456789012-abc….apps.googleusercontent.com. Dois clients com o mesmo número inicial estão no mesmo projeto e mostram a mesma marca.

1. No Google Cloud Console, crie um projeto novo (seletor de projeto no topo → Novo projeto) com o nome do seu produto.
2. Com esse projeto selecionado, vá em APIs e serviços → Tela de permissão OAuth e preencha: nome do app (é o que o usuário lê), e-mail de suporte, logo e domínio.
3. Só então crie o ID do cliente OAuth (passo 1) dentro deste projeto, com a mesma redirect URI.
4. Publique a tela de permissão (Publicar app). Em modo Teste só entram as contas listadas como testadoras.

Trocar as credenciais no dashboard depois é seguro: quem já entrou continua com a conta, porque a identidade é casada pelo e-mail verificado.

GitHub OAuth

1. Acesse github.com → Settings → Developer settings → OAuth Apps → New OAuth App.
2. Homepage URL: URL do seu app.
3. Authorization callback URL: https://auth.superdb.com.br/auth/v1/callback/github
4. Copie Client ID e gere um Client Secret.
5. No dashboard: Autenticação → GitHub → Configurar e cole as credenciais.

No GitHub a marca da tela vem do dono do OAuth App. Para o usuário ver o nome da sua empresa (e não o de uma conta pessoal), crie o App dentro da organização: Settings da organização → Developer settings → OAuth Apps.

Apple Sign In

Apple é oferecido somente no modo gerenciado — a plataforma mantém o Services ID, o Team ID e a chave .p8. Você não precisa da conta paga do Apple Developer Program para usar: no dashboard, em Autenticação, é só ligar o cartão Apple.

A tela de consentimento aparecerá com o nome SuperDB. Se você precisa da sua própria marca no Sign in with Apple, fale com o suporte — credenciais próprias para Apple ainda não são self-serve.

Microsoft / Azure AD

Ainda não disponível. Os provedores suportados hoje são Google, GitHub e Apple. Microsoft/Azure AD e SAML/OIDC genéricos estão no roadmap.

Usando no app (código)

Com o SDK @superdb/client ≥ 0.2.0, web e mobile usam o mesmo fluxo (PKCE): você inicia o login, o usuário volta com um ?code= e você troca esse code por sessão.

// 1) inicia — o SDK gera e guarda o PKCE sozinho
const { data } = await db.auth.signInWithOAuth({
  provider: 'google',
  redirectTo: 'https://meuapp.com.br/auth/callback',  // mobile: 'meuapp://auth'
})
// leve o usuário para data.url (no Expo: WebBrowser.openAuthSessionAsync)

// 2) na volta, com o ?code= da URL:
await db.auth.exchangeCodeForSession(code)
// pronto — sessão salva, db.from() já respeita a RLS do usuário

No React Native o PKCE precisa de WebCrypto: instale expo-crypto (Expo) ou react-native-quick-crypto (bare). O code é de uso único e expira em 5 minutos.

Troubleshooting

Cliquei em "entrar com Google" e voltei sem nada (nem erro)

O redirectTo não está cadastrado em Autenticação → URLs de redirecionamento. O destino é descartado de propósito (não vazar token para URL não registrada) e o usuário cai em /. É a causa nº 1. No web, cadastre a URL absoluta — uma URL relativa (/auth/callback) resolve contra o host de autenticação, não o do seu app.

oauth_not_enabled (400)

O provider não está habilitado nesse projeto, ou está em modo credenciais próprias sem Client ID/Secret válidos. Ligue em Autenticação.

redirect_uri_mismatch

A URI configurada no provider não bate exatamente com a do SuperDB (https://auth.superdb.com.br/auth/v1/callback/<provider>). Verifique se há barra final (/) ou protocolo incorreto (http vs https).

Consent screen não aparece / erro 403

No Google Cloud, o app está em modo Testing. Adicione o email do usuário como testador ou publique o app no OAuth consent screen.

Token expirado imediatamente

Verifique se o relógio do servidor está sincronizado (NTP). Diferença maior que 5 minutos causa rejeição de tokens OAuth.