Tanto o SAML quanto o OpenID Connect oferecem login único (SSO), mas foram desenvolvidos para arquiteturas diferentes. Se você escolher o protocolo de autenticação errado, poderá encontrar problemas complexos de análise XML, desafios na rotação de certificados ou lacunas na integração com dispositivos móveis.

O SAML 2.0 (padrão OASIS, 2005) foi criado para federação de identidades corporativas com base em XML. Apps para web tradicionais que se conectam a IdPs corporativos são os exemplos mais comuns. O OpenID Connect (OpenID Foundation, 2014) estende o OAuth 2.0 com uma camada de autenticação JSON leve, otimizada para APIs, apps móveis e arquiteturas web modernas. A escolha depende da sua plataforma de destino e do que já está presente na sua infraestrutura de identidade.

Exemplo: sua empresa adquiriu uma startup. O app React da startup precisa oferecer suporte tanto para usuários consumidores que se autenticam com o Google (OIDC) quanto para funcionários da sua empresa que se autenticam por meio do provedor de identidade corporativo (SAML). Como um IdP lida com ambos os protocolos, seu app React mantém um único ponto de integração, em vez de implementar fluxos OIDC e SAML separados.

Aspecto	SAML 2.0	OpenID Connect (OIDC)
Foco principal	Enterprise Federation	Autenticação moderna com OAuth 2.0
Formato dos dados	Asserções XML com assinaturas digitais	JSON Web Tokens (JWTs) para tokens de ID
Base	Protocolo de autenticação e federação baseado em XML	Camada de autenticação construída sobre o OAuth 2.0
Transporte	Principalmente vinculações HTTP-POST e HTTP-Redirect (perfil SSO do navegador)	HTTPS com redirecionamentos no canal principal e chamadas diretas para o endpoint de token/UserInfo
Configuração	Trocar metadados XML, gerenciar certificados	Registro de clientes através de documentos de descoberta (.well-known/openid-configuration)
Formato do token	XML assinado (e, opcionalmente, criptografado)	JWTs para tokens de ID; os tokens de acesso são específicos à implementação (embora o OAuth 2.0/OIDC não exija tokens de acesso JWT, eles são cada vez mais comuns)
Indicado para	Ambientes com requisitos legados de federação de governo ou de setores regulamentados	SPAs, apps móveis, microsserviços, login social
Complexidade da integração	Mais alta: análise sintática de XML, gerenciamento de metadados, rotação de certificados	Geralmente mais baixa: análise sintática de JSON, chamadas HTTP simples, configuração facilmente detectável

Diferenças mais importantes: as asserções SAML podem conter hierarquias de atributos complexas para cumprir requisitos empresariais complexos. O OIDC usa escopos (openid, profile, email) para solicitar declarações específicas no token de ID e, opcionalmente, por meio do endpoint UserInfo.

O SAML funciona independentemente do OAuth 2.0. O OIDC sobrepõe a autenticação aos fluxos de autorização do OAuth 2.0, permitindo uma pilha de protocolos unificada tanto para autenticação quanto para autorização.

SAML (fluxo iniciado pelo provedor de serviços): seu provedor de serviços (SP) redireciona os usuários para o IdP com uma AuthnRequest. O IdP os autentica, gera uma asserção assinada contendo os atributos do usuário e a retorna para o Assertion Consumer Service (ACS) do SP via HTTP-POST. Você valida a assinatura e as condições da asserção e, em seguida, concede o acesso. Esse fluxo normalmente envolve vários redirecionamentos de navegador e sobrecarga de processamento XML.

OIDC (fluxo de código de autorização com PKCE): seu app redireciona os usuários para o endpoint de autorização do IdP com os escopos necessários e um desafio de código PKCE. Após a autenticação e o consentimento, o IdP retorna um código de autorização. Você troca esse código (juntamente com o verificador PKCE) por um token de ID e um token de acesso, podendo receber um token de atualização, dependendo do tipo de cliente e da política do IdP. Valide a assinatura JWT, verifique as declarações (iss, aud, exp) e pronto. Esse fluxo geralmente é mais simples de implementar devido ao suporte nativo a JSON/JWT em plataformas modernas.

Selecione o protocolo adequado para sua arquitetura:

Escolha SAML quando estiver:

• Integrando com IdPs corporativos existentes
• Desenvolvendo para o governo ou setores regulamentados que exigem FISMA, FedRAMP ou federação baseada em SAML legada
• Trabalhando com sistemas que já utilizam SAML, onde os custos de migração superam os benefícios
• Lidando com requisitos complexos de atributos de usuário (hierarquias organizacionais aninhadas, declarações personalizadas)

Escolha OIDC quando estiver:

• Desenvolvendo aplicações de página única (React, Vue, Angular) ou apps móveis (iOS, Android)
• Adicionando provedores de login social (Google, GitHub, Apple)
• Criando arquiteturas API-first ou microsserviços que necessitam de tokens de acesso OAuth 2.0
• Começando do zero, sem as limitações de sistemas legados, pois a configuração mais simples do OIDC reduz o tempo de produção
• Priorizando a experiência do desenvolvedor com melhores bibliotecas e documentação

E se precisar de ambos? Os IdPs podem fazer a mediação de protocolo. A aplicação utiliza OIDC ao se conectar com IdPs corporativos baseados em SAML. Assim, você não precisa gerenciar duas implementações de protocolo.

Validação de token

• Para OIDC: verifique as assinaturas JWT usando o JSON Web Key Set (JWKS) publicado pelo IdP, verifique a expiração (exp), valide se o público (aud) corresponde ao seu ID de cliente e confirme se o emissor (iss) corresponde ao seu IdP.
• Para SAML: valide as assinaturas XML, verifique as condições de expiração (NotBefore, NotOnOrAfter) e valide as restrições de público.

Configuração do cliente

Nunca incorpore segredos do cliente em SPAs ou apps móveis; eles ficam visíveis nas ferramentas de desenvolvedor do navegador e nos binários do app. Use Proof Key for Code Exchange (PKCE) para o fluxo de código de autorização. O PKCE protege contra a interceptação do código de autorização sem exigir um segredo, o que é obrigatório para clientes públicos (RFC 7636).

Gerenciamento de sessão

O OIDC herda o suporte a tokens de atualização do OAuth 2.0 para sessões de longa duração. Troque o token de atualização por novos tokens de acesso quando eles expirarem, desde que seu IdP emita tokens de atualização e a configuração do cliente permita isso. O SAML depende de sessões gerenciadas pelo IdP e pelo SP, em vez de um mecanismo de atualização padronizado, e oferece suporte opcional ao Single Logout (SLO), cuja implementação varia entre os IdPs e pode ser difícil de padronizar.

Como lidar com erros

Registre as falhas de autenticação com contexto (registros de data e hora, códigos de erro, IDs do cliente, respostas do IdP) para depuração. Mostre mensagens genéricas de “falha na autenticação” aos usuários. Evite expor detalhes do token, inconsistências nas declarações ou falhas de assinatura que possam auxiliar os invasores.

O OpenID Connect está substituindo o SAML?

Não, eles estão coexistindo. A adoção do OIDC está crescendo rapidamente para apps voltados ao consumidor e desenvolvimento móvel devido à sua base no OAuth 2.0. No entanto, o SAML continua sendo o padrão nos setores corporativo e governamental devido aos investimentos em infraestrutura e aos requisitos de conformidade (FISMA, FedRAMP). A maioria das organizações utiliza ambos os protocolos: OIDC para novas aplicações e SAML para Enterprise Federation.

Qual protocolo é mais seguro?

Ambos proporcionam forte segurança quando implementados corretamente. O SAML utiliza assinaturas XML e criptografia opcional; o OIDC usa assinaturas JWT e HTTPS. A principal diferença: a extensão PKCE do OIDC (RFC 7636) protege clientes públicos, como apps móveis e SPAs, em que os segredos do cliente não podem ser protegidos. O SAML consegue oferecer proteções semelhantes usando vinculação de artefatos ou asserções de detentor da chave, mas esses padrões são menos comuns no desenvolvimento de aplicações modernas. A segurança depende da implementação, não do protocolo escolhido.

Por que os apps móveis preferem OIDC em vez de SAML?

O fluxo de código de autorização do OIDC com PKCE foi criado para clientes públicos, como apps móveis, que não são capazes de armazenar segredos do cliente com segurança. Os tokens JSON do OIDC integram-se nativamente com os SDKs para dispositivos móveis, enquanto o SAML precisa de bibliotecas de processamento XML. O OIDC é compatível com esquemas de URI personalizados (iOS) e App Links (Android) para uma autenticação sem problemas. Os principais provedores oferecem suporte principalmente a fluxos baseados em OIDC para autenticação móvel.

Qual é o melhor caminho de migração do SAML para o OIDC?

Faça a migração de forma gradual. Implemente o OIDC para novas aplicações e mantenha as integrações SAML existentes. Use uma plataforma de identidade compatível com mediação de protocolo para que suas aplicações se comuniquem via OIDC ao se conectarem a IdPs corporativos baseados em SAML. Isso minimiza o risco sem interromper as relações de federação existentes. Muitas empresas mantêm ambientes híbridos durante as fases de transição. Utilize uma plataforma de identidade que lide com a mediação de protocolos, permitindo que as aplicações usem OIDC enquanto a plataforma gerencia a federação SAML.

Qual é a diferença entre OAuth 2.0 e OIDC?

O OAuth 2.0 cuida da autorização (acesso a APIs) com tokens de acesso. O OIDC adiciona autenticação (verificação da identidade do usuário) com tokens de ID baseados no OAuth 2.0. Ao implementar o recurso “Entrar com o Google”, você usa o OIDC para autenticação e o OAuth 2.0 para acesso à API. O OIDC amplia o OAuth 2.0 com declarações de identidade padronizadas e o endpoint UserInfo.

A escolha entre SAML e OIDC é essencial para garantir a segurança da sua arquitetura de autenticação. Ambos os protocolos exigem uma implementação cuidadosa, incluindo validação adequada de tokens, gerenciamento de certificados e tratamento de sessões. Implementar e manter os dois protocolos é um processo complexo.

A Auth0 é compatível com SAML e OIDC, lidando com a mediação de protocolo e as boas práticas de segurança para que os desenvolvedores possam se concentrar nos recursos das aplicações.

Confira nossa série "Introdução ao IAM" para mais informações sobre tópicos relacionados ao 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.