SAML SSO é ativado pela equipe. A configuração da conexão SAML não é self-serve: envie os metadados do seu IdP para o suporte e a equipe habilita no seu projeto. O passo a passo abaixo descreve o que preparar do lado do seu provedor de identidade.
SAML vs OAuth — quando usar cada
OAuth/OIDC (Google, GitHub, Apple) é ideal para aplicações consumer e B2C onde usuários têm contas pessoais em provedores públicos. É mais simples de configurar e funciona em qualquer plano.
SAML 2.0 é o padrão corporativo. Use quando o cliente:
- Usa um Identity Provider (IdP) corporativo como Okta, Azure AD, OneLogin ou ADFS.
- Exige que todos os funcionários autentiquem via o diretório da empresa.
- Precisa de provisionamento automático de usuários (SCIM 2.0).
Ainda não disponível. As rotas de SAML e SCIM respondem 402 hoje, em todos os planos — e não existe plano "Enterprise": os planos são Grátis, Site, Pro e Escala. O passo a passo abaixo é a referência de como a integração vai funcionar quando entrar no ar; nenhum projeto consegue usá-la agora. Se a sua organização precisa disso, fale com a gente — a fila é por demanda real.
Metadados do SP (Service Provider)
O SuperDB atua como o SP (Service Provider) na relação SAML. Você precisará fornecer estes dados ao seu IdP:
Entity ID (Issuer):
https://auth.superdb.com.br/saml/sp
ACS URL (Assertion Consumer Service):
https://auth.superdb.com.br/saml/acs
Metadata XML URL:
https://auth.superdb.com.br/saml/metadata.xml
Binding: HTTP-POST
NameID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Passo a passo com Okta
- No painel Okta, acesse Applications → Create App Integration → SAML 2.0.
- Nome do app: ex. "SuperDB Prod".
- Em SAML Settings:
- Single sign-on URL:
https://auth.superdb.com.br/saml/acs - Audience URI (SP Entity ID):
https://auth.superdb.com.br/saml/sp - Name ID format: EmailAddress
- Attribute statements: adicione
email → user.emailename → user.displayName
- Single sign-on URL:
- Finalize e abra o app criado. Acesse Sign On → View SAML setup instructions.
- Copie o Identity Provider Issuer, o Single Sign-On URL e o X.509 Certificate.
- Envie ao suporte os dados do IdP (Entity ID, SSO URL e certificado X.509) — a equipe cria a conexão no seu projeto.
- Clique em Testar conexão antes de ativar em produção.
Troubleshooting
Certificado expirado
O certificado X.509 do IdP tem validade. Quando expirar, o login SAML retorna signature_invalid. Envie o novo certificado ao suporte antes do vencimento — a troca é feita sem derrubar as sessões ativas.
Atributos não mapeados
Se o email do usuário não chega no atributo correto, verifique os Attribute Statements no Okta. O SuperDB espera o email em email ou NameID.
InResponseTo mismatch
Ocorre quando o IdP responde a um request que já expirou ou foi processado. Garanta que o relógio do servidor esteja sincronizado (máximo 5 minutos de diferença).