polarisSSO · Setup técnicoEntrar →
Polaris · Raravis Consulting

Configurar SSO no Polaris.

Single Sign-On do Polaris via Google Workspace ou Microsoft Entra ID (OAuth 2.0 / OIDC). Esta página é o material técnico que o seu TI usa para configurar o login corporativo da sua organização. Conteúdo destinado a administradores de identidade e DPO.

OAuth 2.0
Google · Microsoft
OIDC
openid · email · profile
SAML 2.0
Sob demanda · enterprise
JIT
Provisionamento automático
Allowlist
Defesa em profundidade
01

Resposta rápida

Para TI e DPO do cliente que precisa de uma resposta de uma página.

PerguntaResposta
Suporta SSO?Sim. Habilitado por padrão em todos os tenants.
Protocolos suportadosOAuth 2.0 / OIDC (Google Workspace, Microsoft Entra ID) e Magic Link + OTP por e-mail. SAML 2.0 sob demanda.
Provider de identidadeSupabase Auth (gerenciado). IdPs externos são configurados no console do Supabase pelo time Raravis.
Multi-fator (MFA)Herdado do IdP do cliente. Se o Google/Microsoft exige MFA, o Polaris herda automaticamente.
Provisionamento (SCIM)Não automático. JIT na primeira autenticação contra a allowlist. SCIM 2.0 está no roadmap.
AllowlistObrigatória. Só e-mails cadastrados entram, mesmo com OAuth bem-sucedido.
Documentação técnicaEsta página. URL compartilhável: https://polaris.raravis.com.br/trust/sso
02

Arquitetura do fluxo

Polaris delega autenticação a um broker (Supabase Auth) que troca tokens com o IdP do cliente via OAuth 2.0 / OIDC. Tudo padrão, sem cliente customizado.

Cliente ──1. click──▶ Polaris /login │ │ 2. signInWithOAuth({ provider }) ▼ Supabase Auth (broker gerenciado) │ │ 3. redirect OAuth 2.0 / OIDC ▼ IdP do cliente (Google Workspace ou Microsoft Entra ID) │ │ 4. authorization code ▼ Supabase /auth/v1/callback │ │ 5. troca code por sessão ▼ Polaris /auth/callback │ ├─ valida allowlist ├─ cria user_profile (JIT) └─ redireciona pro app
03

URLs de callback

O TI do cliente precisa cadastrar a URL de callback do Supabase no Console do IdP. As URLs abaixo valem para o ambiente de produção da Raravis.

FunçãoURL
Página de loginhttps://polaris.raravis.com.br/login
Callback do Polaris (recebe code do Supabase)https://polaris.raravis.com.br/auth/callback
Callback do Supabase (cadastrar no IdP)https://api.polaris.raravis.com.br/auth/v1/callback
Esta página (compartilhar com cliente)https://polaris.raravis.com.br/trust/sso
api.polaris.raravis.com.br é o custom domain do projeto Supabase de produção (gerenciado pela Raravis). Para clientes que exigem projeto Supabase dedicado, o time Raravis fornece a URL de callback específica do tenant.
04

Habilitar Google Workspace

Roteiro para o TI configurar OAuth 2.0 no Google Cloud Console. ~15 minutos.

  1. 1Acesse Google Cloud Console → APIs & Services → Credentials.
  2. 2Create Credentials → OAuth client ID.
  3. 3Application type: Web application.
  4. 4Authorized JavaScript origins: https://api.polaris.raravis.com.br.
  5. 5Authorized redirect URIs: https://api.polaris.raravis.com.br/auth/v1/callback.
  6. 6Salve e copie Client ID + Client Secret.
  7. 7Em OAuth consent screen, configure User Type → Internal. Isto restringe o login a usuários do seu domínio Workspace.
  8. 8Envie credenciais pro time Raravis via canal seguro (1Password, Bitwarden compartilhado, ou e-mail criptografado). Habilitamos no console do Supabase do seu tenant em até 1 dia útil.
Mesmo sem a restrição “Internal”, a allowlist do Polaris impede acessos de e-mails não cadastrados — defesa em profundidade.
05

Habilitar Microsoft Entra ID (Azure AD)

O Polaris usa um app multilocatário próprio da Raravis. Seu TI só autoriza (consent) — não precisa criar app nem gerar secret. ~5 minutos.

Diferente do modelo tradicional, você não cria um App registration nem gera client secret. O Polaris já tem um app multilocatário registrado pela Raravis; seu administrador apenas o autoriza no tenant da sua organização.

  1. 1Peça pro time Raravis o Application (client) ID do app Polaris.
  2. 2Um Application Administrator ou Global Administrator do seu tenant abre, logado no Entra da sua organização: https://login.microsoftonline.com/<seu tenant ID>/adminconsent?client_id=<client ID do Polaris>.
  3. 3Revise as permissões solicitadas (delegated): User.Read, email, openid, profile — só leitura de perfil básico, nenhum acesso a dados sensíveis.
  4. 4Clique em Aceitar. Pronto: usuários da sua organização que estiverem na allowlist passam a logar com Microsoft.
Seu tenant ID é público — pode confirmar emhttps://login.microsoftonline.com/<seu domínio>/v2.0/.well-known/openid-configuration (campo issuer). Nada de secret pra renovar do seu lado: o secret vive no app da Raravis, que cuida da rotação.
06

SAML 2.0 (sob demanda)

Disponível para clientes enterprise com IdP corporativo (Okta, Ping, OneLogin, ADFS, etc.). Requer upgrade no plano e 1-2 dias de configuração.

Por padrão o Polaris não tem SAML habilitado. Habilitamos por tenant quando o cliente exige por política interna. Pré-requisitos:

  • Upgrade do plano Supabase do tenant (Pro+ tem SAML SSO).
  • IdP entregando Entity ID, SSO URL e certificado X.509 público.
  • 1-2 dias úteis de configuração + teste end-to-end.

Atributos SAML mínimos consumidos: email (NameID ou attribute),given_name (opcional), family_name (opcional). Provisionamento JIT igual ao OAuth.

07

Allowlist e provisionamento JIT

Polaris confia no IdP só para autenticação. A autorização passa por duas camadas adicionais.

Allowlist por e-mail
Admin RH cadastra previamente os e-mails autorizados. Login com e-mail fora da lista é negado mesmo se o OAuth no IdP foi bem-sucedido. Sem allowlist, sem entrada.
JIT provisioning
Na primeira autenticação válida, o usuário é criado automaticamente em user_profiles e associado à organização correta. Nenhum cadastro prévio de profile é necessário — só a entrada na allowlist.
SCIM 2.0
Sincronização automática de usuários entre o IdP do cliente e o Polaris está no roadmap (prioridade média). Hoje, alta em massa é feita via importação CSV no módulo Equipe.
MFA
Herdado do IdP. Se o Google Workspace ou Microsoft Entra do cliente exige MFA, o Polaris herda automaticamente — não há configuração nem MFA proprietário do lado Polaris.
08

Troubleshooting

Sintomas comuns durante setup e a ação que resolve.

SintomaCausaAção
redirect_uri_mismatch (Google) ou AADSTS50011 (Microsoft)URI no IdP não bate com https://api.polaris.raravis.com.br/auth/v1/callbackTI do cliente confere e ajusta no IdP.
Login OAuth funciona mas Polaris diz "acesso negado"E-mail não está na allowlist da organização.Admin RH adiciona o e-mail via painel administrativo ou via importação CSV.
Magic link funciona em desktop mas falha em webview de e-mail mobilePKCE state perdido entre webview e browser externo.Usar o código OTP de 6 dígitos que vem junto no e-mail. O campo aparece na tela de login depois do envio do magic link.
Client secret do Microsoft expirouSecret tem validade máxima de 24 meses. Vive no app multilocatário da Raravis.Nada do seu lado: o time Raravis rotaciona o secret no próprio app e atualiza o Supabase. Durante a janela, magic link por e-mail segue como fallback.
Cliente quer restringir login só ao domínio delePolaris não filtra por domínio no lado da aplicação.Configurar restrição no IdP: Google User Type: Internal, Microsoft single tenant + Conditional Access.
09

Como solicitar

TI do cliente envia as credenciais pelos canais abaixo. Raravis habilita no console do Supabase do tenant em até 1 dia útil.

SituaçãoCanal
Habilitar Google Workspace ou Microsoft Entra IDonboarding@raravis.com.br
Avaliar SAML 2.0 enterpriseonboarding@raravis.com.br
Encarregado de proteção de dados (DPO)privacy@raravis.com.br
Reportar vulnerabilidadesecurity@raravis.com.br