O SAML é um protocolo de autenticação e federação que possibilita o acesso com Single Sign-On (SSO) em ambientes corporativos. Já o OAuth 2.0 é uma estrutura de autorização que concede acesso delegado a APIs usando tokens de acesso.

A autenticação e a autorização são a base do gerenciamento de identidade e acesso (IAM), mas os protocolos que as facilitam (como SAML e OAuth 2.0) servem a propósitos diferentes, embora relacionados. Quando usados em ordem incorreta ou fora de suas finalidades, surgem lacunas de segurança e riscos arquitetônicos desnecessários.

Exemplo: sua empresa usa Salesforce, Slack e um portal interno de RH. Com o SAML, você faz login uma única vez no diretório corporativo e tem autenticação imediata nos três (SSO corporativo). Quando deseja permitir que uma ferramenta de análise de terceiros acesse seus dados do Salesforce sem compartilhar sua senha, você usa o OAuth 2.0. O OAuth 2.0 fornece autorização delegada para recursos específicos.

SAML 2.0:

• Autentica o usuário e possibilita o SSO corporativo
• Responde à pergunta “Quem é este usuário?”
• Utiliza afirmações XML com atributos de identidade
• Indicado para: Enterprise Federation, SSO para força de trabalho

OAuth 2.0:

• Autoriza o acesso aos recursos sem compartilhar credenciais
• Responde à pergunta: “Quais recursos este usuário pode acessar?”
• Emite tokens de acesso (e, opcionalmente, tokens de atualização) para autorização de API
• Indicado para: segurança de API, apps móveis, acesso de terceiros

O OpenID Connect (OIDC) é uma camada de identidade baseada em OAuth 2.0 que adiciona autenticação por meio de tokens de identificação.

Embora ambos sejam padrões abertos, seus propósitos são diferentes. O SAML 2.0 foca na autenticação (AuthN) e no SSO, respondendo à pergunta: Quem é este usuário? Por outro lado, o OAuth 2.0 foca na autorização (AuthZ), respondendo à pergunta: O que este usuário pode acessar?

O SAML foi desenvolvido para federação de identidade em contextos corporativos e governamentais. O OAuth 2.0 é uma estrutura de autorização desenvolvida para acesso delegado, frequentemente utilizada para proteger APIs modernas e aplicativos de consumo.

• SAML 2.0 (padrão OASIS, 2005)
• OAuth 2.0 (IETF RFC 6749, 2012)
• OpenID Connect (OpenID Foundation, 2014)

Aspecto	SAML 2.0	OAuth 2.0
Meta principal	Autenticação e SSO corporativo	Autorização e acesso delegado
Formato dos dados	XML (afirmação de segurança)	O OAuth 2.0 é agnóstico em relação ao formato do token, uma vez que a maioria das implementações usa JWTs, embora tokens opacos também sejam aceitos
Artefatos principais	Afirmações XML assinadas, metadados de federação (fora do canal)	Tokens de acesso, escopos
Transferência de identidade	Integrada: as afirmações carregam atributos de identidade de forma explícita (por exemplo, função ou e-mail)	Não integrada: os tokens de acesso comprovam apenas a autorização; o OpenID Connect adiciona declarações de identidade
Adoção	Identidade corporativa da força de trabalho, sistemas legados.	APIs, apps móveis/nativos, microsserviços
Complexidade do token	Alta (análise de XML, assinaturas digitais)	Moderada (os JWTs exigem as seguintes validações: assinatura, declaração e do ciclo de vida da chave; os tokens opacos exigem introspecção)

O SAML usa XML para suas afirmações de segurança. O XML exige sobrecarga adicional para análise sintática e validação de assinatura, resultando em mensagens maiores que podem afetar o desempenho em ambientes de alto volume de dados.

O OAuth 2.0 não define o formato do token. Os JSON Web Tokens (JWTs) são comuns, mas não obrigatórios. Esses tokens são compactos e simplificados, sendo geralmente validados por meio de verificação de assinatura, validação de declaração e rotação de chaves. Por isso são ideais para aplicativos móveis e para ampliar a autorização da API. Já com os tokens opacos, a validação é realizada pela introspecção do token em vez de usar verificações locais de assinatura.

A principal distinção reside naquilo que o artefato central de cada protocolo comprova.

As afirmações de SAML são uma declaração direta da identidade e dos atributos de um usuário emitida por um provedor de identidade (IdP). Um aplicativo pode confiar na afirmação para confirmar a identidade do usuário e o grupo ao qual ele pertence.

Os tokens de acesso OAuth 2.0 apenas comprovam a autorização para acessar um recurso específico. O token não comprova a identidade do usuário. O uso apenas do OAuth 2.0 para autenticação, sem uma extensão como OIDC, cria uma brecha de segurança, pois o token de acesso não verifica a identidade do usuário.

As principais diferenças entre os protocolos estão nos fluxos:

• O SAML enfatiza a confiança preestabelecida pela troca de metadados e retorna os dados de identidade diretamente, em afirmações XML assinadas por meio de redirecionamentos de navegador.
• O OAuth 2.0 utiliza códigos de autorização como uma etapa intermediária, com o cliente trocando códigos por tokens em um endpoint de back-end, para ajudar a viabilizar a entrega segura de tokens sem expô-los no navegador.

Use o SAML quando precisar de:

Requisitos do SSO corporativo

• Gerenciamento de identidades centralizado
• SSO integrado em vários aplicativos empresariais
• Troca complexa de atributos de usuário (departamento, função, grupo)

Conformidade regulatória

• Declarações de atributos integradas para auditabilidade e governança
• Compartilhamento explícito de dados de identidade para relatórios de conformidade

Federação corporativa e governamental
O SAML é amplamente utilizado para federação de identidade corporativa e governamental, incluindo plataformas corporativas modernas e sistemas legados. As plataformas de identidade corporativa e governamental normalmente aceitam SAML e OIDC para cumprir diferentes requisitos de integração.

Use o OAuth 2.0 quando precisar de:

Segurança de API

• Proteção de APIs REST com escopos de controle de acesso granular
• Autorização sem estado para microsserviços
• Segurança de API baseada em token

Apps móveis e nativos

• Formato JSON simplificado e código de autorização com chave de prova para troca de código (PKCE)
• Redirecionamentos seguros baseados em navegador usando navegadores do sistema em vez de visualizações web incorporadas

Acesso de terceiros

• Delegação de permissões específicas sem compartilhar credenciais
• Login social (login com Google, Facebook)
• Acesso limitado ao escopo dos dados do usuário

O OIDC é uma camada de identidade construída sobre o OAuth 2.0. Esse protocolo introduz tokens de identificação para autenticação do usuário, padronizando o modo em que as declarações de identidade são representadas enquanto continua a usar o OAuth 2.0 para emitir tokens de acesso para autorização da API. O OIDC não substitui o OAuth 2.0, mas o estende para oferecer suporte à autenticação e à identidade. No fluxo moderno, o OIDC lida com a autenticação (emissão de tokens de identificação), enquanto o OAuth 2.0 lida com a autorização (emissão de tokens de acesso para chamadas da API). Ambos geralmente trabalham juntos no mesmo fluxo.

Destaque	OAuth 2.0	OIDC (extensão do OAuth 2.0)
Saída primária	Token de acesso (autorização)	Token de identificação (autenticação)
identidade	Não (somente autorização)	Sim (declarações de identidade, perfil do usuário)

1. Tratar o OAuth 2.0 como autenticação

• Os tokens de acesso do OAuth 2.0 comprovam a autorização, não a identidade.
• Use o OpenID Connect para autenticação ou para implementar verificação adicional.

2. Validação de token inadequada

• SAML: validar assinaturas, verificar condições de expiração (NotBefore/NotOnOrAfter), verificar público.
• OAuth 2.0: validar assinatura, expiração (exp), público (aud), emissor (iss) e, opcionalmente, não anterior a (nbf).
• O método de validação depende do tipo de token: verificar o JWT localmente ou usar introspecção para tokens opacos.

3. Confiar em fluxos inseguros para clientes públicos

• Aplicativos nativos não podem armazenar com segurança os segredos do cliente (ou seja, eles são clientes "públicos").
• Utilize o fluxo de código de autorização com PKCE para clientes públicos a fim de evitar a interceptação do código de autorização. (Fluxos sem PKCE, como o fluxo Implicit Grant, estão obsoletos e devem ser evitados em todos os novos desenvolvimentos.)

Qual é a principal diferença entre SAML e OAuth 2.0?

O SAML é usado para autenticação (determinar a identidade do usuário), enquanto o OAuth 2.0 é usado para autorização (decidir o que o usuário pode acessar). O SAML é usado para SSO corporativo e o OAuth 2.0 para controle de acesso à API.

O OAuth 2.0 pode substituir o SAML para SSO?

O OAuth 2.0 sozinho não pode substituir o SAML para SSO porque ele é estritamente uma estrutura de autorização. O OIDC (baseado no OAuth 2.0) adiciona a camada de autenticação necessária para SSO, mas, ao contrário do SAML, suas especificações de logout único são extensões opcionais que as implementações tratam separadamente.

Qual protocolo é mais seguro?

Quando implementados corretamente, tanto o SAML quanto o OAuth 2.0 oferecem fortes garantias de segurança. Os riscos acontecem quando há erros na implementação, incluindo ausência de validação de assinatura, tratamento inadequado do tempo de vida dos tokens, verificações fracas de público e emissor ou um endpoint de autorização mal configurado. O SAML oferece assinaturas em mensagens e criptografia opcional, enquanto o OAuth 2.0, combinado com PKCE e validação adequada do token, fornece uma segurança equivalente. A seleção do protocolo deve priorizar a adequação arquitetural em vez das suposições de segurança.

Preciso aceitar ambos os protocolos?

A maioria dos aplicativos não precisa de ambos para uso interno. No entanto, pode ser necessário aceitar os dois ao integrar com provedores de identidade externos. Os clientes corporativos geralmente exigem o SAML, enquanto apps para consumidores esperam login social via OAuth 2.0. As plataformas de identidade fazem a tradução do protocolo.

Por que as APIs preferem o OAuth 2.0 ao SAML?

As APIs preferem o OAuth 2.0 porque os tokens são menores e mais fáceis de analisar do que as afirmações XML. Além disso, a autorização baseada em escopo mapeia diretamente para as permissões da API, e as linguagens de programação modernas têm suporte superior para bibliotecas do OAuth 2.0.

A escolha entre SAML e OAuth 2.0 depende dos requisitos do seu aplicativo e dos cenários de integração. Ambos os protocolos protegem o gerenciamento de identidade e acesso quando implementados corretamente.

A utilização de uma plataforma de identidade como a Auth0 elimina a complexidade dos protocolos, sendo compatível com SAML, OAuth 2.0 e OpenID Connect. Seu aplicativo autentica os usuários por meio de uma API consistente, independentemente do protocolo subjacente. Explore a série Introdução ao IAM e saiba mais sobre protocolos de identidade e arquiteturas de autenticação moderna.

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.