16 de nov. de 2025·8 min
OAuth vs SAML para SSO: o que compradores empresariais esperam
OAuth vs SAML para SSO explicado em termos simples, além do que empresas pedem, o que construir e como manter seu login atual funcionando.
OAuth vs SAML para SSO explicado em termos simples, além do que empresas pedem, o que construir e como manter seu login atual funcionando.
SSO vira prioridade no momento em que um acordo sai de um "trial por equipe" para um rollout em toda a empresa. Um comprador pode adorar seu produto, mas segurança e TI vão atrasar a compra se funcionários tiverem de criar novas senhas, gerenciar MFA em mais um lugar ou deixar contas para trás quando mudam de função.
Para muitas empresas, SSO é menos sobre conveniência e mais sobre controle. Elas querem um único lugar para aplicar regras de login, revogar acesso rapidamente e mostrar aos auditores que identidade é gerida centralmente. Por isso a pergunta "OAuth vs SAML para SSO" aparece no final do ciclo de vendas: é uma forma rápida de checar se você se encaixa na infraestrutura de identidade deles.
Adicionar SSO tarde pode quebrar suposições que você já tem. Se seu modelo atual é "um email = um usuário", o SSO traz casos de borda como aliases compartilhados, múltiplos provedores de identidade ou usuários que precisam manter login por senha e SSO durante uma migração. Se o link de conta estiver errado, pessoas perdem acesso ou, pior, ganham acesso ao tenant errado.
SSO também muda onboarding e suporte. Feito certo, reduz resets de senha e tickets de "quem é o dono desta conta?". Feito errado, rollouts emperram, administradores ficam irritados e renovações ficam em risco porque o produto "funcionou no trial" mas falha no dia um da implantação empresarial.
A decisão raramente pertence a uma só pessoa. O comprador quer momentum, segurança checa riscos e auditoria, admins de TI precisam de passos claros de configuração, usuários finais querem um login suave, e suporte acaba lidando com bloqueios, migrações e exceções.
Se você constrói apps em plataformas como Koder.ai, vale planejar SSO cedo para não redesenhar identidade depois que clientes já estão ativos.
SSO (single sign-on) significa que seu cliente entra no seu app usando o login da empresa, não uma senha separada que você armazena. Eles fazem login com a conta do trabalho e o acesso é controlado pela política da empresa.
Estes são os termos que você ouvirá em chamadas com empresas:
Quando as pessoas dizem "OAuth login", frequentemente querem dizer OpenID Connect (OIDC). OAuth é principalmente sobre autorização (permissão para acessar algo). OIDC adiciona autenticação (quem é o usuário), então pode ser usado para login.
SAML é um padrão SSO mais antigo, baseado em XML. Empresas ainda o usam muito porque é comprovado, amplamente suportado pelos IdPs e está presente em muitos checklists de compliance.
SCIM não é SSO. SCIM é para provisionamento: criar, atualizar e desativar usuários (e às vezes grupos) automaticamente. Uma configuração comum é SAML ou OIDC para sign-in, mais SCIM para que acesso seja adicionado e removido sem trabalho manual do admin.
Compradores empresariais geralmente não começam pelos detalhes do protocolo. Começam por risco e controle: "Podemos gerenciar acesso a partir do nosso IdP e provar quem fez o quê?"
A maioria das equipes empresariais quer ao menos uma opção amigável ao ambiente corporativo, e muitas querem ambas:
Também perguntarão como funciona a configuração: metadata ou discovery URL, rotação de certificados e se o time de TI pode fazer self-serve sem esperar seus engenheiros.
A forma mais rápida de perder um acordo empresarial é ser vago sobre offboarding. Eles perguntarão o que acontece quando um funcionário sai, muda de departamento ou perde um laptop.
Espere perguntas como:
Um cenário simples que eles se importam: um admin desativa um usuário às 9:02 e, às 9:03, esse usuário não deveria conseguir abrir o app, mesmo que ainda tenha uma aba do navegador aberta. Se você não explicar esse fluxo claramente, espere ciclos extras de revisão.
OAuth foi criado originalmente para acesso delegado: permitir que um sistema chame a API de outro sem compartilhar senha. Muitos times ainda o usam para isso (por exemplo, uma integração que lê calendários). Para login de funcionários, a maioria dos produtos usa OpenID Connect (OIDC), que se apoia em OAuth e adiciona uma forma padrão de provar quem é o usuário.
Com OIDC, o setup comum é o authorization code flow. Seu app envia o usuário ao IdP da empresa para fazer login. Depois de um login bem-sucedido, o IdP devolve ao seu app um código de autorização de curta duração. Seu backend troca esse código por tokens.
A divisão de tokens que importa:
Uma forma prática de pensar em OAuth vs SAML para SSO: OIDC é ótimo quando você quer um login moderno que se encaixe em padrões web, mobile e de API. SAML é mais comum quando a empresa quer o handshake clássico de "sign in to the app" e se importa menos com acesso a APIs.
O que armazenar deve ser simples: o identificador estável do usuário (subject), o email (se fornecido) e a conexão de tenant utilizada. O que você não deve armazenar é a senha do usuário. Também evite guardar refresh tokens de longa duração, a menos que realmente precise de acesso offline a APIs.
Para fazer isso funcionar por tenant, você precisará de:
Feito certo, os usuários voltam para seu app, você valida os tokens e cria sua sessão normal sem reescrever todo o modelo de autenticação.
SAML permite que um IdP empresarial diga ao seu app: "esta pessoa já fez login, aqui estão os detalhes dela." O IdP envia uma assertion SAML, que é basicamente uma nota assinada que inclui quem é o usuário (e às vezes informações de grupo ou função) mais uma janela de validade curta.
Para tornar essa nota confiável, o SAML se baseia em metadata e certificados. Metadata é um pequeno pacote de configuração que descreve endpoints e chaves. Certificados são usados principalmente para assinatura, para que seu app confirme que a assertion veio do IdP do cliente e não foi alterada.
Dois identificadores aparecem em quase todo setup:
Se qualquer um estiver errado, o login falha mesmo que todo o resto pareça correto.
SAML no mundo real é tanto operações quanto código. Planeje configurações de SAML por tenant, rotação de certificados sem downtime, clock skew (mesmo alguns minutos podem quebrar assertions) e erros claros para admins (não apenas "invalid response").
Um padrão comum: o admin do cliente habilita SAML por tenant, então seu app verifica a assinatura, checa se a assertion não expirou e mapeia o email (ou NameID) para um usuário existente ou aplica uma regra segura de auto-provision. Na prática, este é o cerne da decisão OAuth vs SAML: SAML costuma forçar workflows administrativos mais robustos.
Escolher entre OIDC e SAML é mais sobre o que o comprador já usa. Muitos apps B2B acabam suportando ambos com o tempo, mas você ainda pode tomar uma decisão limpa por cliente e manter seu sistema de auth previsível.
OIDC costuma ser mais suave para apps modernos. Ele se encaixa bem em navegadores e mobile, lida bem com APIs e geralmente é mais fácil de depurar e estender (scopes, tempos de vida de token etc.). Se seu cliente empresarial já usa um IdP moderno e o time de TI está confortável com OIDC, comece por aí.
SAML pode ser inegociável. Muitas grandes empresas têm programas SAML e regras de onboarding como "apenas SAML". Nesses casos, a melhor abordagem é implementar SAML uma vez de forma controlada e mantê-lo isolado do resto do seu sistema de login.
Perguntas a fazer antes de se comprometer:
Um guia rápido de decisão:
| Se o cliente disser... | Preferência | Por quê |
|---|---|---|
| "Usamos Entra ID e queremos integração moderna" | OIDC | Melhor encaixe para flows web e API |
| "Nossa política é apenas SAML para fornecedores" | SAML | Necessário para passar onboarding de segurança |
| "Precisamos de ambos para diferentes subsidiárias" | Ambos | Comum em organizações grandes |
| "Precisamos de claims customizados por app" | Ambos | Ambos suportam mapeamento de atributos |
Se você suportar ambos, mantenha o resto do app consistente: um modelo interno de usuário, um modelo de sessão e um conjunto de regras de autorização. O método SSO deve responder "quem é este usuário e a qual tenant ele pertence" — não reescrever como acesso funciona.
Comece definindo o que "tenant" significa no seu produto. Para a maioria dos apps B2B, SSO é configurado por organização ou workspace, não por usuário. Essa escolha dirige onde você armazena configurações de IdP, quem pode alterá-las e como usuários se movem entre workspaces.
Depois, escolha um comportamento de login previsível. Roteamento por domínio (digite email, então redirecione se o domínio tiver SSO) reduz confusão, mas você deve lidar com casos de borda como contratantes e empresas com múltiplos domínios. Um botão simples "Continuar com SSO" é mais fácil de entender, mas usuários podem escolher a opção errada.
Uma ordem segura de implementação para OIDC ou SAML:
Testes não são opcionais. Use um IdP sandbox e um tenant de staging com domínios realistas. Execute caminhos felizes e casos de falha: certificado expirado, audience errada, clock skew, usuário removido do IdP. Trate rollout de SSO como um feature flag.
Plataformas como Koder.ai facilitam esse tipo de iteração ao suportar snapshots e rollback junto com configuração por tenant, assim uma mudança ruim não bloqueia todos os clientes ao mesmo tempo.
SSO não é só um botão de login. Times de segurança vão perguntar sobre duração de sessão, offboarding e o que você pode provar quando algo dá errado. Se tratar SSO como parte central do seu sistema de auth (não um complemento), você evita a maioria das escaladas dolorosas.
Comece com regras de sessão. Escolha um timeout de inatividade e uma duração absoluta de sessão, e seja claro sobre o que acontece quando alguém fecha o laptop e volta no dia seguinte. Com OIDC, refresh tokens podem manter sessões vivas além do esperado, então defina limites (rotação, idade máxima) se os usar. Com SAML, sessões de navegador podem durar muito tempo a menos que você force re-autenticação.
Logout é outra armadilha. "Single logout" não é universal. Suporte logout local de forma confiável e documente que logout global entre todos os apps depende do IdP.
MFA é similar. Empresas querem que o IdP imponha MFA, então seu app deve aceitar um usuário autenticado sem pedir novamente. Ainda assim, é útil suportar step-up para ações de risco (exportar dados, mudar billing), porque nem toda política de IdP é perfeita.
Provisionamento de usuários é onde vazamentos de acesso acontecem. JIT provisioning é conveniente, mas pode criar contas para qualquer um que se autentique. Invite-only é mais seguro, mas adiciona trabalho de admin. Muitas equipes chegam a um meio-termo: JIT permitido, mas restrito por domínios permitidos e (opcionalmente) claims de grupo.
Mantenha configuração de SSO protegida por papéis de privilégio mínimo. Alguém não deveria precisar de super-admin só para rotacionar um certificado ou atualizar uma URL de IdP.
Para suporte, logue o suficiente para rastrear um login sem armazenar segredos:
Essa é a diferença entre "não conseguimos reproduzir" e resolver uma queda de SSO empresarial em minutos.
Uma empresa de médio porte chega no procurement e diz: "Precisamos de SSO antes de assinar." Isso raramente é filosófico. É um controle necessário para onboarding, offboarding e auditoria.
Agora a virada: você está vendendo para duas equipes. Time A fica satisfeito com OIDC porque usam Okta com apps modernos. Time B insiste em SAML porque suas ferramentas legadas ainda dependem dele. Aqui a pergunta OAuth vs SAML deixa de ser debate e vira um plano de rollout.
Mantenha uma regra: SSO é uma opção de login por-tenant, não uma substituição global. Usuários existentes ainda podem entrar do jeito antigo até o admin do tenant ativar "SSO obrigatório."
No primeiro login SSO, você precisa de vinculação de conta segura. Uma abordagem limpa é: combinar por email verificado, confirmar o tenant pelo domínio (ou um convite) e então anexar a identidade do IdP ao usuário existente. Se não houver correspondência, crie o usuário just-in-time, mas somente se o admin permitiu.
A atribuição de papéis é onde acordos ficam presos. Mantenha simples: um papel padrão para novos usuários e mapeamento opcional de grupos/claims do IdP para seus papéis.
No lado do admin, normalmente precisam configurar:
Para evitar lockouts durante a troca, mantenha uma conta admin break-glass fora do SSO, rode um modo de teste para os primeiros logins e só imponha SSO depois de pelo menos uma sessão admin confirmada funcionando.
A maioria dos incidentes de SSO não é causada pelo IdP. Acontecem porque seu app trata SSO como um switch global em vez de uma configuração por cliente.
Uma falha clássica é esquecer limites de tenant. Uma nova configuração de IdP é salva globalmente e, de repente, todo cliente é redirecionado para o último IdP que você tocou. Mantenha configurações de IdP ligadas ao tenant e sempre resolva o tenant antes de iniciar o handshake SSO.
O próximo grande problema é o matching de contas. Se depender apenas de email, você criará usuários duplicados ou bloqueará usuários reais quando o email no IdP for diferente do email usado antes do SSO. Defina sua política de merge desde o início: quais identificadores você confia, como lidar com mudanças de email e como admins podem corrigir incompatibilidades sem ajuda de engenharia.
Times também tendem a confiar demais em claims. Valide o que recebe: issuer, audience, assinatura e se o email está verificado (ou use um identificador estável como subject). Aceitar audience errada ou email não verificado é uma maneira fácil de dar acesso a pessoa errada.
Quando algo falha, erros vagos geram longas ligações de suporte. Dê aos usuários uma mensagem clara e aos admins uma dica diagnóstica (por exemplo: "Audience mismatch" ou "Certificate expired") sem expor segredos.
Questões relacionadas ao tempo merecem testes antes de lançar. Clock skew e rotação de certificados quebram logins numa segunda-feira às 9h.
Cinco checagens que evitam a maioria das outages:
SSO é onde pequenas suposições viram grandes tickets de suporte. Antes de dizer a um cliente empresarial que você suporta SSO, confirme que o básico funciona no seu produto, não apenas em uma demo.
Execute estes passos em um ambiente de staging que espelhe produção:
Faça um exercício completo de "dia ruim": rotacione um certificado, mude um claim ou quebre a URL do IdP e confirme que dá para detectar e reagir rapidamente.
Depois confirme monitoramento e alertas para falhas de SSO (por tenant), mais um plano de rollback (feature flag, reverter config ou deploy rápido) que você já praticou.
Escolha um ponto de partida claro. A maioria dos compradores empresariais pede "SAML com Okta/Entra ID" ou "OIDC com Google/Microsoft", e você não quer prometer ambos na semana um a menos que tenha time para isso. Decida o que vai suportar primeiro (apenas SAML, apenas OIDC ou ambos) e documente o que "pronto" significa para produto e suporte.
Antes de envolver um cliente real, crie um tenant demo interno. Use-o para ensaiar o fluxo completo: habilitar SSO, testar login, restringir a um domínio e recuperar acesso quando algo der errado. É também onde seu playbook de suporte é testado.
Mantenha um documento vivo de requisitos empresariais. Revisões mudam com o tempo, e ter um lugar para rastrear o que você suporta evita promessas pontuais que depois quebram o onboarding.
Um plano simples que funciona na prática:
Se quiser avançar rápido no lado do produto, você pode prototipar telas de configuração e a estrutura de tenants em Koder.ai (koder.ai) e iterar conforme chegarem questionários de segurança de clientes.
Planeje os complementos que costumam seguir logo após o SSO: SCIM, exportações de logs de auditoria e papéis de admin com permissões claras. Mesmo que você não os entregue imediatamente, compradores vão perguntar e sua resposta deve ser consistente.
A maioria das equipes empresariais quer controle centralizado sobre o acesso. SSO permite que eles imponham MFA e regras de login no provedor de identidade, removam acesso rapidamente quando alguém sai e atendam requisitos de auditoria sem depender do seu app para gerenciar senhas corretamente.
Comece pelo que o provedor de identidade do cliente já suporta e pelas políticas de onboarding de fornecedores. OIDC costuma ser a opção mais suave para fluxos web e mobile modernos, enquanto SAML é frequentemente obrigatório em empresas maiores por ser um padrão amplamente adotado em setups legados.
OIDC é uma camada de autenticação sobre OAuth projetada para login. OAuth sozinho trata principalmente de autorização para APIs, não de provar quem é o usuário. Se você está implementando "Entrar com o IdP da empresa", quase sempre quer dizer OIDC em vez do OAuth puro.
Não. SSO é sobre autenticar usuários, enquanto SCIM trata do provisionamento automático: criar, atualizar e desativar contas de usuário (e às vezes grupos). Um setup comum é SAML ou OIDC para login e SCIM para que offboarding e mudanças de função não dependam de trabalho manual no seu app.
Trate SSO como uma configuração por-tenant, não como um switch global. Resolva o tenant primeiro (por roteamento por domínio, convite ou seleção explícita de organização) e então inicie o handshake SSO usando a configuração do IdP desse tenant. Isso evita que a configuração de um cliente afete outros.
Use um identificador estável do IdP (como o sub do OIDC ou um SAML NameID) como vínculo primário e trate o email como atributo secundário que pode mudar. No primeiro login SSO, vincule a uma conta existente apenas quando houver confiança de que é a mesma pessoa e o tenant estiver correto; caso contrário, exija convite ou confirmação do admin.
Mantenha uma conta de administrador break-glass que possa entrar sem SSO e deixe o SSO opt-in até um admin verificar que funciona. Também forneça um toggle único para desabilitar o SSO daquele tenant caso a configuração do IdP quebre, permitindo que o suporte restaure o acesso sem alteração de código.
Dê suporte a logout local de forma confiável no seu app e explique que o logout global em todos os apps depende das funcionalidades e da configuração do IdP do cliente. Planeje revogação rápida de acesso expirando sessões ou rechecando o estado do usuário para que um usuário desativado não continue usando o app em uma aba antiga do navegador.
Foque em logs de erro de SSO por tenant que ajudem a identificar a falha sem armazenar segredos. Capture um ID de correlação, o tenant, o issuer/entity ID, timestamps e um motivo claro como falha de assinatura, mismatch de audience ou certificado expirado. Evite armazenar tokens brutos, assertions SAML completas, client secrets ou chaves privadas nos logs.
Você precisa de armazenamento de configuração por nível de tenant, uma UI de admin para gerenciar configurações de IdP, regras seguras de vinculação de conta e um caminho de rollback. Se construir sobre Koder.ai, planeje o modelo de tenants cedo e use snapshots e rollback durante o rollout para que uma mudança ruim não impeça todos os clientes de entrarem.