O Security Assertion Markup Language (SAML) 2.0 é um protocolo baseado em XML que permite a federação de identidades entre domínios de segurança distintos para fornecer Single Sign-On (SSO). O SAML permite que os usuários se autentiquem com um provedor de identidade (IdP) uma única vez e, em seguida, acessem vários provedores de serviços (SPs) sem precisar inserir suas credenciais novamente.

O SAML 2.0 foi ratificado como um padrão aberto da OASIS em 2005. Continua sendo amplamente utilizado para federação de identidades em empresas e governos, embora o OpenID Connect (OIDC) tenha se tornado cada vez mais comum em aplicações modernas.

Exemplo: ao fazer login no hub interno da sua empresa, o SAML permite que você acesse repositórios do GitHub Enterprise, tickets do Jira e documentação do Confluence imediatamente ao longo do dia sem precisar fornecer suas credenciais outra vez para cada ferramenta. O portal funciona como um iniciador de aplicações hospedado por um SP ou um IdP, enquanto as ferramentas subsequentes (Jira, GitHub Enterprise) são SPs adicionais que confiam no mesmo IdP.

O SAML aceita dois padrões de iniciação, ambos resultando em SSO.

Fluxo iniciado pelo SP (padrão para SaaS B2B)

Quando um usuário tenta acessar a aplicação diretamente:

1. O usuário tenta acessar a aplicação (SP)
2. A aplicação redireciona o usuário para a página de login do IdP
3. O usuário se autentica com o IdP
4. O IdP gera uma asserção SAML assinada
5. O IdP redireciona o usuário de volta para a aplicação com a asserção
6. A aplicação valida a assinatura da asserção e cria uma sessão
7. Usuário acessa a sua aplicação

Fluxo iniciado pelo IdP (comum em ambientes corporativos)

Quando um usuário inicia a partir do painel corporativo:

1. O usuário faz login no portal corporativo (IdP)
2. O usuário clica na aplicação no painel dele
3. O IdP gera uma asserção SAML assinada
4. O IdP redireciona o usuário para a aplicação automaticamente (SP) com a asserção
5. A aplicação valida a asserção e cria uma sessão
6. O usuário acessa a aplicação

Ambos os fluxos verificam a identidade sem exigir o compartilhamento de senhas entre os sistemas. O IdP pode pedir a autenticação multifatorial (MFA) antes de emitir a asserção, adicionando uma camada extra de segurança.

O SSO iniciado pelo IdP não inclui um valor InResponseTo do SP. Os SPs dependem mais dos registros de data e hora das asserções (NotBefore/NotOnOrAfter) e da proteção contra repetição ao validar as asserções iniciadas pelo IdP.

O SAML permite a federação de identidades por três componentes principais:

• IdP: sistema que autentica usuários e armazena credenciais
• SP: aplicação que depende do IdP para autenticação e concessão de acesso
• Asserção SAML: documento XML assinado digitalmente contendo dados de identidade verificados, transmitidos do IdP para o SP

A asserção confirma a identidade do usuário e o acesso que ele está autorizado a ter, permitindo que o SP conceda ou negue acesso sem lidar diretamente com as credenciais do usuário.

Uma asserção SAML é um documento XML estruturado com três tipos de declarações:

• Declarações de autenticação: verifique se o usuário está autenticado e registre o horário em que o evento ocorreu.
• Declarações de atributos: contêm dados e declarações do usuário (e-mail, nome, grupos, funções). A maioria das implantações transmite dados de autorização (como funções ou grupos) pelas declarações de atributos. Em implantações SAML para a força de trabalho, as declarações de atributos geralmente incluem dados relacionados à autorização, como grupos ou funções.
• Declarações de decisão de autorização: definidas na especificação SAML, mas raramente usadas nas implementações de SSO atuais.

A asserção inclui:

• Emissor: qual IdP criou
• Sujeito: quem é o usuário
• Condições: período de validade (por exemplo, NotBefore e NotOnOrAfter) e público-alvo
• Assinatura: prova criptográfica de autenticidade. O SP deve verificar se o elemento que está sendo processado é o mesmo elemento referenciado pelo ID da assinatura para evitar ataques XML Signature Wrapping.

A asserção pode ser criptografada — normalmente, o elemento <Assertion>, em vez de toda a <Response> — embora atributos individuais também possam ser criptografados para dados sensíveis. O SP deve ser capaz de descriptografar elementos criptografados, se necessário.

Os desenvolvedores costumam confundir SAML com OAuth 2.0 e OIDC. Veja a comparação:

Aspecto	SAML 2.0	OAuth 2.0	OpenID Connect
Uso principal	Autenticação SSO corporativa	Autorização delegada	Autenticação moderna
Formato	XML (análise complexa; risco de ataques XML Signature Wrapping)	A especificação não define o formato do token, embora muitas implementações usem tokens de acesso JWT	Baseado em JSON (token de ID JWT)
Tipo de token	Asserção SAML	Token de acesso	Token de ID e token de acesso
Transporte	As solicitações de autenticação geralmente usam HTTP-Redirect; as asserções são quase sempre entregues via HTTP-POST	Normalmente, via cabeçalho de autorização HTTP (bearer tokens), embora existam outros métodos de transporte (form_post/query) dependendo do fluxo	Cabeçalho de autorização HTTP
Suporte móvel	Suporte deficiente para apps nativos (frequentemente requer WebView ou um app intermediário)	Excelente	Excelente
Público-alvo	Empresas, governos	Apps para consumidores, APIs	Apps para consumidores, empresas modernas
Caso de uso	SSO corporativo, autenticação da força de trabalho	Delegação de acesso à API, integrações de terceiros	Apps modernos, autenticação móvel, SSO do consumidor

O OAuth 2.0 cuida da autorização (o que você pode fazer), não da autenticação (quem você é). O OAuth 2.0, isoladamente, não é um protocolo de autenticação. Os provedores geralmente usam métodos proprietários para adicionar informações de identidade; no entanto, esses métodos não são padronizados. O OpenID Connect é o padrão para adicionar autenticação ao OAuth 2.0.

O SAML lida com a autenticação e pode incluir atributos de autorização, mas não é uma estrutura de autorização. As decisões de autorização são tomadas na sua aplicação após a conclusão da autenticação SAML.

Os protocolos não são mutuamente exclusivos. Muitas plataformas de identidade aceitam as três opções, permitindo que você escolha com base nas necessidades dos seus usuários.

Validação de assinatura XML

O SAML depende de assinaturas XML para segurança. A implementação correta da validação é complexa:

• Validar o algoritmo de assinatura (rejeitar algoritmos fracos como SHA-1)
• Verificar a cadeia de certificados de assinatura
• Verificar o status de expiração e revogação do certificado
• Conferir se o elemento assinado corresponde ao conteúdo analisado
• Os SPs devem validar pelo menos uma assinatura confiável (na <Response> ou na <Assertion>, dependendo da configuração) e garantir que apenas o elemento esperado seja processado.
• Os SPs devem garantir que a assinatura cubra a referência correta para evitar o ataque de XML wrapping. Algumas bibliotecas podem não exigir cobertura de referência. Verifique se a assinatura faz referência ao ID do elemento correto.

Um único erro na validação de assinatura cria vulnerabilidades de segurança. Os invasores podem explorar ataques XML-Signature Wrapping para burlar a autenticação.

Você pode usar uma biblioteca SAML já testada em vez de criar uma do zero.

Desvio do relógio e validação do registro de data e hora

As asserções SAML incluem condições (NotBefore) e (NotOnOrAfter). Diferenças de relógio entre o IdP e o SP podem fazer com que asserções válidas sejam rejeitadas.

Boas práticas:

• Permita uma tolerância de 2 a 5 minutos no desvio do relógio.
• Implemente a configuração NTP adequada nos seus servidores.
• Registre as falhas de validação do registro de data e hora separadamente para depuração.

Troca de metadados

O SAML normalmente usa a troca de metadados entre o IdP e o SP, embora isso não seja estritamente exigido pela especificação:

• Metadados do IdP: contêm certificados de assinatura, endpoints e ID da entidade.
• Metadados do SP: descrevem os URLs e requisitos do Assertion Consumer Service (ACS) da sua aplicação

Alterações nos metadados interrompem o SSO. Quando os IdPs rotacionam os certificados, é necessário atualizar a configuração. Algumas empresas exigem aprovação manual para alterações nos metadados do SP, o que pode atrasar as implantações.

Armazene os metadados do IdP em seu banco de dados, não em arquivos de configuração. Nem todos os IdPs suportam URLs de metadados dinâmicos. Quando disponível, a atualização automática é a melhor prática.

Inconsistências no mapeamento de atributos

IdPs diferentes enviam nomes de atributos diferentes. A aplicação precisa de um mapeamento de atributos flexível para lidar com essas variações. Permita que os clientes configurem quais atributos SAML correspondem aos campos de usuário da sua aplicação.

Usando o controle de acesso baseado em funções (RBAC), os IdPs podem enviar informações de função em atributos SAML. A aplicação deve mapear essas funções do IdP para o sistema de permissões interno.

Sempre valide a assinatura

Cada asserção SAML deve ser validada criptograficamente para confirmar se:

1. A assinatura existe.
2. A assinatura é válida para o conteúdo da asserção.
3. A cadeia de certificados de assinatura leva a uma raiz confiável.
4. O elemento assinado corresponde ao conteúdo analisado. Os SPs devem garantir que a assinatura cubra a referência correta para evitar o ataque de XML wrapping.

Nunca ignore a validação de assinatura, nem mesmo durante o desenvolvimento. Ela é a base da segurança de SAML.

Valide todas as condições da asserção

Além das assinaturas, valide se:

• Emissor: corresponde ao IdP configurado
• Público-alvo: contém o ID da entidade da aplicação
• NotBefore/NotOnOrAfter: o horário atual está dentro do período válido
• Destinatário: corresponde ao URL do Assertion Consumer Service (se houver)
• InResponseTo: corresponde ao seu ID de solicitação de autenticação (para fluxos iniciados pelo SP)

Previna ataques de repetição e Signature Wrapping

A especificação SAML não exige o uso único de asserções, deixando o SP responsável pela proteção contra repetição.

1. Armazene o ID da asserção (não o ID da resposta), usado como um nonce para evitar repetição, em um cache com TTL correspondente ao período de validade da asserção.
   Boa prática: defina o TTL do cache para, no mínimo, o valor da janela NotOnOrAfter da asserção, idealmente com um pequeno buffer (alguns segundos) para compensar a latência da rede.
2. Rejeite qualquer asserção com um ID que você já tenha visto antes.
3. Limpe os IDs expirados regularmente para gerenciar o tamanho do cache.

Como primeira linha de defesa, o SP deve validar os registros de data e hora NotBefore e NotOnOrAfter. O armazenamento em cache dos IDs de asserção é secundário.

Utilize HTTPS em todos os locais

As asserções SAML devem ser transmitidas apenas por HTTPS. Mesmo que sejam assinadas, a transmissão por HTTP expõe os usuários a ataques do tipo Man-in-the-Middle.

Configure o URL do Assertion Consumer Service (ACS) apenas com HTTPS. A maioria dos IdPs emitirá avisos ou bloqueará endpoints HTTP.

Implemente o logout corretamente

O SAML é compatível com o Single Logout (SLO), permitindo que os usuários saiam de todas as aplicações conectadas simultaneamente. A implementação é opcional, mas recomendada para aplicações que exigem alta segurança.

O SLO pode ser front-channel (redirecionamentos do navegador) ou back-channel (servidor para servidor). O SLO front-channel é amplamente aceito, mas é frágil. Existe um método de logout back-channel, mas ele é complexo e raramente implementado. A interoperabilidade varia, uma vez que diferentes IdPs e SPs implementam o SLO de maneiras diferentes. Portanto, é provável que você precise testar vários provedores.

A implementação de um sistema SAML seguro do zero exige profundo conhecimento em segurança XML e geralmente é recomendada apenas para implementações de IdP ou casos de uso altamente especializados.

Analise as suas opções:

Plataformas de identidade

Algumas plataformas de identidade ajudam a lidar com a complexidade do SAML fornecendo:

• Implementações pré-configuradas de IdP e SP SAML
• Gerenciamento automático de metadados
• Gestão da rotação de certificados
• Suporte para vários IdPs por aplicação
• Registros de auditoria detalhados

Essa abordagem oferece suporte a SAML para clientes corporativos, ao mesmo tempo que utiliza protocolos modernos (OIDC, OAuth 2.0) para aplicações voltados ao consumidor. Algumas plataformas fazem a conversão entre protocolos sem problemas.

Bibliotecas SAML

Para equipes que precisam de mais controle, bibliotecas SAML consolidadas cuidam da análise de XML, validação de assinatura e detalhes de protocolo de baixo nível:

• Node.js: passport-saml, samlify
• Python: python3-saml, pysaml2
• Java: Spring Security SAML, OpenSAML
• .NET: Sustainsys.Saml2, ITfoxtec.Identity.Saml2
• Ruby: ruby-saml
• PHP: SimpleSAMLphp

Nem mesmo as bibliotecas SAML consolidadas lidam automaticamente com ataques de repetição ou asserções criptografadas. Os desenvolvedores devem implementar o armazenamento em cache/nonces e a descriptografia conforme necessário, além de garantir que a referência da assinatura seja verificada.

Escolha SAML quando estiver:

• Com clientes que são empresas com infraestrutura de SAML existente
• Construindo um SaaS B2B que exige SSO corporativo
• Fazendo a integração com sistemas governamentais
• Com respostas à RFP que exigem suporte para SAML

Escolha OIDC ou OAuth 2.0 quando estiver:

• Desenvolvendo aplicações voltadas aos consumidores
• Precisando de autenticação para apps móveis
• Implementando autorização de API
• Dando preferência a protocolos mais simples baseados em JSON
• Começando do zero, sem requisitos legados

Muitas aplicações aceitam diferentes protocolos. Seu IdP deve aceitar SAML para clientes corporativos e OIDC para todos os outros usuários. Você pode usar métodos de autenticação sem senha, como WebAuthn e chaves de acesso, para melhorar a experiência do usuário.

Antes de implementar o suporte SAML, realize testes completos:

Teste com vários IdPs

Cada IdP implementa o SAML de uma forma ligeiramente diferente. Não presuma que o comportamento de um IdP se aplica aos outros. Os nomes dos atributos, os formatos dos metadados e o tratamento dos certificados variam.

Teste de casos extremos

• Desvio do relógio (ajuste o horário do seu servidor em ±5 minutos)
• Rotação de certificados (atualize os certificados do IdP e verifique se não há tempo de inatividade)
• Assinaturas inválidas (adultere as asserções e confirme a rejeição)
• Asserções expiradas (use asserções de teste antigas)
• Ataques de repetição (reenvie asserções válidas e confirme a rejeição)

Falhas de validação do monitor

Registre todas as falhas de validação do SAML com o ID da asserção, o motivo, a entidade IdP e o registro de data e hora para fins de depuração. Os registros são essenciais para a depuração dos problemas dos clientes. As falhas do SAML geralmente são causadas por problemas de configuração, não por erros de código.

Qual problema o SAML resolve?

Para possibilitar o SSO, o SAML permite a federação de identidades para usuários corporativos. A principal vantagem dele é simplificar a segurança da aplicação transferindo a responsabilidade pelo armazenamento e gerenciamento de senhas de usuários para um IdP dedicado. Isso reduz a superfície de ataque da aplicação, diminui as chamadas para o suporte técnico para redefinição de senhas e centraliza a imposição de políticas.

É autenticação ou autorização SAML?

O SAML é principalmente um protocolo de autenticação e federação, criado para verificar a identidade do usuário. Não é, por si só, uma estrutura de autorização como o OAuth 2.0. O SAML responde à pergunta “Quem é este usuário?” transmitindo uma asserção assinada (uma declaração de identidade) de um IdP para um SP. A autorização (determinar o que o usuário pode fazer) ocorre após a conclusão da autenticação SAML, em geral pelos atributos do usuário (por exemplo, função ou departamento) encontrados na asserção SAML.

Qual é a diferença entre SAML, OAuth 2.0 e OpenID Connect?

O SAML é um padrão mais antigo, baseado em XML, criado para federação de identidades corporativas e SSO da força de trabalho. O OAuth 2.0 é uma estrutura de autorização que emite tokens de acesso para conceder acesso delegado e de escopo limitado a APIs. O OIDC é uma camada de identidade construída sobre o OAuth 2.0 que adiciona autenticação padronizada com tokens de ID (JWTs), otimizada para aplicações web, móveis e baseadas em API. Os três permitem o acesso, mas o SAML se concentra no SSO corporativo, enquanto o OAuth e o OIDC são mais adequados para a autenticação de aplicações e autorização de API atuais.

O SAML ainda é usado?

Sim. O SAML continua sendo um protocolo dominante para SSO corporativo, principalmente em grandes organizações e agências governamentais com infraestrutura de identidade já existente. Embora o OIDC tenha ganhado força em aplicações, a ampla adoção do SAML no ambiente corporativo significa que ele continua sendo usado ativamente e recebendo suporte.

O SAML é seguro? Quais são os riscos para a segurança?

O SAML é seguro quando implementado corretamente. O protocolo usa assinaturas digitais XML e criptografia para proteger os dados de identidade. Os riscos podem surgir da validação inadequada das asserções. Os SPs devem verificar as assinaturas XML, validar as condições da asserção (incluindo emissor, público-alvo e registros de data e hora) e implementar a proteção contra repetição.

A Auth0 ajuda os desenvolvedores a implementar o SAML de forma rápida e segura, permitindo o SSO corporativo sem a necessidade de construir ou manter uma infraestrutura de SAML do zero.

Confira nossa série "Introdução ao IAM" sobre gerenciamento de identidade e acesso.

Saiba mais

Este material destina-se apenas a fins informativos gerais. Você é responsável por obter aconselhamento sobre segurança, privacidade, conformidade ou negócios de seus próprios consultores profissionais e não deve confiar exclusivamente nas informações aqui fornecidas.